Re: RPG SSL Sockets

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Chris,

That should be no problem.  But, in that case you do want to use the 
GSK_OS400_APPLICATION_ID.  Then you can set up the Client Certificate, 
et al, in the Digital Certificate manager and associate it with that 
application id.

-SK

On 11/6/2014 8:33 AM, Chris Bipes wrote:
> Actually that is very clear and my exact understanding.  However looking at the new spec that I am going to have to write to, I may need that client certificate.
>
> Just not good enough to be a private line with encryption, but may have to identify myself as well.  (even though their router is in my server room..)
>
> Oh the paranoia today, but with good reason.
>
> Chris Bipes
> Director of Information Services
> CrossCheck, Inc.
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
> Sent: Wednesday, November 05, 2014 11:56 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: RPG SSL Sockets
>
> Hi Chris,
>
> My service program approach is quite a bit different from what you
> describe.  I never let my caller get to the actual descriptor...  I
> encapsulate all the stuff like selects, reads, writes, etc into the
> service program.
>
> This way, I can do stuff under the covers like buffering the data (since
> I never have to worry about the caller doing send/recv/read/write
> directly, I can buffer data to improve speeds).   The caller can do
> either SSL or plain text without having to call a separate set of APIs,
> because the raw implementation is not available to it, etc.
>
> This, of course, makes the service program fairly complex -- but the
> applications are pretty simple, and can focus on the application's logic
> rather than on network logic.
>
> Regarding client certificates:  Keep in mind that 99% of the SSL
> connections made do not use client certificates. So when you're talking
> about this, you're talking about the "normal" way of doing SSL.
>
> The purpose of certificates is to ensure that your data is sent to the
> entity that you THINK it's being sent to. If you are a shopper buying
> things from Acme.com's web site, and you're about to type a credit card
> number into the page, it's simply not good enough to know that the data
> will be encrypted.  You also have to know that you're REALLY at Acme's
> web site. It's easy for Joe Hacker to grab Acme's logo and put up a web
> site that looks like Acme.com.  You don't want to encrypt your CC, and
> send it securely so that only Joe Hacker can decrypt it -- what good is
> that?  The certificate tells you that it's really Acme, and not Joe Hacker.
>
> On the other hand, it's not usually necessary for Acme to know that
> you're really Chris Bipes.  If you have Chris's userid, password and
> credit card, that's good enough for Acme.  Expecting every consumer to
> register for their own SSL certificate just to buy goods would not work.
>
> So, server-side certificates are required.  Client side are not for most
> applications.
>
> If you do not plan to use client-side ceritificates, then you can create
> the application without GSK_OS400_APPLICATION_ID if you prefer.  The
> application ID associates your program with settings in the Digital
> Certificate Manager -- but if you'd rather just always use default
> settings, and don't want to have to configure things in the DCM, you can
> replace the GSK_OS400_APPLICATION_ID code with this, instead:
>
> rc = gsk_attribute_set_buffer( SslEnv
>                                : GSK_KEYRING_FILE
>                                : '*SYSTEM'
>                                : 0);
>
> That tells it to use the default settings for the *SYSTEM certificate
> store instead of setting up an application ID, et al.
>
> Clear as mud?