|
Scott, I guess you've never had a B2B relationship with a partner that mandates something better than Basic Authentication. The partner would usually issue you with a client certificate to permit you to access their server. We had to develop web applications for a customer who is a national bank where they would not even permit their browser clients access without a trusted client certificate. I suspect it will become more common in this age of identity fraud. For SSL connections that do not require a client certificate we have created RPGLE that binds to the SSL versions of the TCP sockets procedures. The entire code is not too verbose without even bothering to strip prototypes and methods into a service program. Although the SSL socket APIs prior to V5 required a reference to the certificate store containing the digital certificate used to encrypt the session, since then only the Application ID assigned by the DCM is necessary, just like in the IBM GSKit (which does seem verbose). Not having seen any example of using a client cert in RPGLE it seemed as clear as mud how this might be achieved (even in the GSKit). However, I notice that there is a reference to a local certificate in a data structure which has been set to *null, maybe that's what I've missed. The thing about embedding a cert in the header seemed a reasonable assumption since that's how authentication appears to be prescribed by RFCs, which for me appear to make digital cert stuff look too hard compared with Basic Authentication. If you figure you can prove how do it with GSKit then that would be nice to know. We can always stick with the java classes that achieve this but, like you, I have a penchant for knowing how to do it in RPGLE. Peter -----Original Message----- From: rpg400-l-bounces+peter.connell=baycorpadvantage.com@xxxxxxxxxxxx [mailto:rpg400-l-bounces+peter.connell=baycorpadvantage.com@xxxxxxxxxxxx ]On Behalf Of Scott Klement Sent: Saturday, October 25, 2003 10:08 AM To: RPG programming on the AS400 / iSeries Subject: Re: Sockets and client certificate You need client certs in HTTP? I've never heard of that requirement. At any rate, client certs are part of SSL, not part of HTTP. You don't encode them in the HTTP header, but rather you put them in the SSL handshake. Although I haven't tested it, my HTTPAPI should already do that if you assign a client certificate to the application in the digital certificate manager. Have you considered using HTTPAPI (or similar) solution instead of writing the HTTP code yourself? http://www.scottklement.com/httpapi/ On Sat, 25 Oct 2003, Peter Connell wrote: > Using sockets in RPGLE to send an HTTP request to a remote HTTP server > has long been standard fare. Using SSL sockets proved a little more > difficult with much thanks to some sample RPGLE code from Barbara Morris > a couple of years ago. > > It is also clear how to embed base64 encoded authentication details into > the HTTP header for connection to sites that require Basic > Authentication. But does anyone know how to accomodate a site that > requires a client certificate for authentication. I did a brief google > search for RFCs on this but they prove to be tiresome. > > I would like to think that it's as simple as knowing the correct HTTP > directives to embed the header and then just copy in the client > certificate directly from where it is stored on the IFS but that may be > wishful thinking. It would be also be nice to be able to dump a > communication trace for such a request but it is unfortunately > unreadable since it is encrypted. I presume that would also be the case > for some tool that might expose the header when using a browser to > connect. > > Finding info on this stuff seems like looking for a needle in a haystack. > Can anyone help? > _______________________________________________ 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-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.