On Mon, Aug 10, 2015 at 2:34 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

*>I'd rather have something that allows you to supply a certificate and
have it automatically import the CA chain into a certificate store.*

What do we gain by using IBM's cert store? Wouldn't we rather have the
SSLCertificate* Apache directives and use openssl (PASE command) to
quickly/easily take care of business?


Because IBM's SSL APIs use IBM's cert store. And the SSL APIs are used by
most applications that require SSL on the IBMi (either the standard or
GSKKit APIs).

These are client apps for the most part as well. So Apache would have
nothing to do with it.

Example... when you visit a site with your PC that your browser doesn't
trust, it gives you the option to trust it (in other words, your client app
allows to you automatically import the CAs) with a click or two of your
mouse.

On the IBM i, you just get RC(-23). It would be nice to provide the
certificate in this case (or even an URL) and say "hey, import the CA chain
and "trust" this site."

Instead, those ISVs with apps that use SSL need to try and explain to the
end user to how first export the Certificate from the site, then strip out
the CA chain, then import them in using DCM. That is, if the user doesn't
get frustrated before asking for help with the issue and just dump the
product all together.

For the user it's once every 10 years they need to do this (when the server
updates their certificate). But, as an ISV that provides SSL client apps,
it means I help 10 customers a week with this (even with the documentation
I provide).

Even worse, if a CA or cert expires that's not even used by any application
it throws a -24 RC error... Explained here:
http://www.fieldexit.com/forum/display?threadid=182

That's a little off topic, but maybe something you could ask IBM while
working with them on this. :)

Brad
www.bvstools.com

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.