|
I had the same problem when I was getting my HTTPAPI to work with SSL. I fixed it by: WRKLNK '/QIBM/UserData/ICSS/Cert/Server/*' and then I changed the DEFAULT.KDB and DEFAULT.RDB to be *RX. I think I made sure all of the directories below them were *RX as well. The only differences between what I'm saying, and what you're saying that I can see is that I changed the authority for *PUBLIC, not just a single user, and I changed the files to *RX instead of *R. Not sure why that would make a diff, though. I assume you checked to make sure the app was registered to the same certificate store that you checked the authorities on? On Thu, 21 Feb 2002, Brad Stone wrote: > Got a quick question. > > I have a customer who is using my GETURI tool. They are > running it from a web CGI job, so user profile QTMHTTP1 is > the one being used for authorities, etc. > > When runing GETURI and doing an SSL request (using sockets > Apis) to a server, they get an error saying that the user > does not have the proper authorities to the keyring file. > > If they change the HTTP config to use a different user > profile, it works fine. > > I searched the docs and didn't find anything on what special > authorities one needs for this. User QTMHHTP1 has *RX to > all directories in the keyring path, as well as *R to the > keyring file. > > So, I'm assuming it's a special authority that is needed. > Would anyone here know for sure? I am using the C APIs to > make SSL socket connections in the GETURI tool. > > Thanks! > > Brad > www.bvstools.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.