× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.