|
I guess, as is often the case, any statement regarding digital certs can easily be interpreted as confusing. Nevertheless, I stand by what I said. To be clear then, the important point is that in order to get the SSL app to work I must of course assign, via the DCM, some client cert, which of course has it's associated list of trusted CAs, even though the remote server requires no authentication. That cert may of course be one the iSeries itself has issued. But where the server does require authentication by digital cert then I achieve this by using the client cert furnished by the enterprise with which I am connecting and assigning that to the app. In fact, you may be pleased to know Scott, that despite geting the app to work using the APIs as Brad is attempting (me make fire too), with the localCertificate pointer set to *null, I resorted to your LIBHTTP/HTTPAPI to save further development because you've done a good job on the error recovery side. Once the client cert was assigned to the app that binds to your service pgm it also worked a treat. Peter -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement Sent: Monday, January 19, 2004 10:43 AM To: RPG programming on the AS400 / iSeries Subject: RE: Question on allocating Storage > It appears that using the iSeries as a client for negotiating both the > SSL session and the authentication is a little different than when a PC > performs the same. The PC normally has a root cert used to negotiate the > SSL session. Where the server requires Basic Authentication then that is > sufficient. Where The PC normally has a root cert used to negotiate the > SSL session. The PC and the iSeries are exactly the same. You're confusing the act of validating the server's certificate with the act of sending your own client certificate -- two very different things. Sending the client certificate is an optional bit which isn't done when talking to public web servers because the server doesn't need to trust the client. However, in private business dealings it's very common for both sides to have to authenticate each other. Basic Authentication has nothing whatsoever to do with SSL. It's part of HTTP, and can be used with or without SSL being involved, and with or without client authentication involved. > Where the server requires a digital cert for authentication then it is > necessary to import a totally separate cert ( possibly from a totally > separate CA) into the PC in order to implement this. > > However, the iSeries appears to make no such distinction for the similar > senario. It provides only for assigning a single cert to an application > via the DCM, which you are undoubtedly aware of since I know you have > already written such software. Not true. The iSeries definitely does make a distinction! When you click on "Manage trusted roots" (or some similar name) you're telling the DCM which server certificates your client trusts. When you're setting up a client application and assigning a certificate to it, you're assigning a client cert that it sent when client authentication is enabled. You may be confused by the fact that in pre-V5R1 versions of OS/400, it was not possible to set up a secure application without assigning a client certificate. That was an oversight which IBM corrected. However, you still had separate "trusted root" vs. "application certificate" settings. The system has always distinguished between them. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. ##################################################################################### This correspondence is for the named person's use only. It may contain confidential or legally privileged information, or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Baycorp Advantage. If you need assistance, please contact Baycorp Advantage on either :- Australia 133124 or New Zealand +64 9 356 5800
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.