RE: Sockets and client certificate -- RPG400-L

Never mind. I guess I should have tried it before asking (isn't that always the 
way).
We do indeed use the open source code kindly furnished by Barbara Morris so 
there was no need to look elsewhere at all, just a couple of lines to change.
As I indicated, the code uses the traditional SSL_APIs supported by OS400, and 
as I suspected, it is the localCertificate data structure entry which provides 
for client authentication via digital cert. This makes it easy to code such a 
socket program from scratch, not much more difficult than regular sockets.

fyi: A client certificate provided by another party for authenticating with 
their server is independent of the iSeries DCM which provides the cert for the 
underlying SSL session that transports the client cert etc.   


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Saturday, October 25, 2003 7:52 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Sockets and client certificate




> I guess you've never had a B2B relationship with a partner that mandates
> something better than Basic Authentication.

HTTPAPI supports both Basic Authentication and Digest Authentication.  And
they can be used with or without SSL.   I believe that it also supports
a client-side certificate... but I haven't tested that.

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

I've done this with telnet, but not with HTTP.

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

HTTPAPI uses GSKit.

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

The RFCs define BASIC and DIGEST authentication.  They do not talk about
certificates.  I'm assuming, therefore, that you're talking about SSL
certificates


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

As I said in the previous message, I believe my HTTPAPI already DOES do
this, all you have to do is assign it a cert in Digital Certificate
Manager.

Please download it and try it and see if it does what you want to do.  If
it does, you're free to use it, rather than writing your own HTTP
routines.   It's open source, so it costs you nothing.  If for some
obscure reason you don't want to use it, feel free to read the code and
learn how it works.

That's part of the beauty of open source -- you can learn from other
people's code.

http://www.scottklement.com/httpapi/

_______________________________________________
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