|
Brad, Correct, the program interface with the cert is via the Application ID (via the DCM). It need not be otherwise reference by the localCertificate pointer. The only use I had thought have for it was as a mechanism by which the current SSL certificate details could be returned to user for some purpose, like when the user can click on the little certificate icon in a browser session. So I'd intended to parse such info out of the cert by passing the local cert to another API. Seems the format was never correct so I gave it a miss finally. I'm not sure whether your mention of "client" cert relates to using a certificate to establish the iSeries as an SSL enabled RPGLE client or if it means that in addition to that you wish to also use a client cert to authenticate with the remote server. It's undoubtedly the second option. 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 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. This is fine if the remote server uses SSL but does not authenticate using a client cert (eg Basic or none), which obviously means that you can have one RPGLE client that could be used to connect to various servers. But if it does then you have to import that cert ( the one needed for authentication ) into the DCM and use that cert as the one you assign to client application program. In other words, it looks like the iSeries client restricts you to using the same cert for both SSL and for authentication. From memory there was a bit of jiggery-pokery to importing the client cert into the DCM to do with the format in which it was exported so you may need to use your PC to re-import/export it. Consequently, a separate application is required for each remote server that requires authentication via digital cert. At least that's the only way I could see that it worked. Cheers, Peter -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Brad Stone Sent: Saturday, January 17, 2004 2:34 AM To: RPG programming on the AS400 / iSeries Subject: Re: Question on allocating Storage The local certificate assigned to the application is what is used for client authentication, from what I understand. After initializing the job/application for SSL using SSL_Init_Application the rest of the SSL APIs know how the session has been initialized. What API are you attempting to use that you need to pass along the local certificate to? And for what purpose? On Fri, 16 Jan 2004 15:45:33 +1300 "Peter Connell" <Peter.Connell@xxxxxxxxxxxxxxxxxxxx> wrote: > Yes, mine is an RPGLE client also. > So what is your need for using the localCertificate > variable if it works without it anyway. > Peter > _______________________________________________ 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.