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?
On 11/5/2014 4:32 PM, Chris Bipes wrote:
Thank you Scott. Believe it or not I found the same question I asked you a couple of years ago. (Well further back than that but I don't want to date myself.)
I have downloaded your SSLClient and SSLSever code from iProDeveloper and have two systems talking.
I was looking a building a service program that I can do something like:
CrtSSLclientConnection
URL
Port
and return the descriptor to do the selects, reads, and writes to.
Make the application simple but the service program do the work.
Now if I do not specify a client certificate, I can still get a secure connection to the server, but don't identify myself. Is this a true statement?
The client does not have to have the GSK_OS400_Application_ID set or does it? I know a server does to present the correct SSL certificate but does the client? This is where I am fuzzy brained.
midrange.com
