|
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-2025 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.