Re: RPG SSL Sockets

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?