Forums >> IBM Power Systems >> (QGPL) IBM i
IBM i (AS/400) and the Wonderful World that is Secure Sockets Layer (SSL) - A Rant
by: bvstone

Jump to: 


IBM i (AS/400) and the Wonderful World that is Secure Sockets Layer (SSL) - A Rant

IBM i (AS/400) and the Wonderful World that is Secure Sockets Layer (SSL) - A Rant

Having created many applications that use TCPIP communications (mainly client side) that means implementing SSL or TLS is inevitable.  

Our GETURI and MAILTOOL products use sockets and SSL/TLS very heavily, and in the future I can see them being becoming even more popular than they are now simply because the email APIs provided by IBM for the IBM i simply don't work with SSL and/or TLS.  They may in the future, but most likely at a global level (and be a bear to set up), not a global, user, or command level like our software provides.

The Big Problem
But, there is a big problem that for some reason still exists even at V7R2.  And that's how Certificates and Certificate Authorities (CAs) that are expired and used in NO WAY by any client application that requires SSL or TLS can cause an application to throw an error.  RC(-24) SSL_ERROR_CERT_EXPIRED.

I posted this question on the MIdrange-L mailing list but got no replies or suggestions.

This makes absolutely ZERO sense.

If the client application was using a client side SSL certificate and that certificate was expired then yes, I could see this error occurring.  

If the client application was communicating with a server in which the CA(s) installed on the system (allowing us to "trust" the server's SSL Certificate) was expired then yes, I could see this happening.  But only if the CA was associated with the server's SSL Certificate in some way.

Because this issue normally shuts down production, it's one of those "Get it fixed fast, now, and I don't care how!" moments.  Which means, once it's fixed, we wash our hands of the problem and don't report it to IBM.

The "Fix"
I probably assist at least one customer a week with this issue.  

First I have to explain to them the problem, and that it's not related to our software.  It's an IBM issue.  Then you must explain that somewhere on their system is an SSL Certificate or CA that is expired and they need to delete it from their system.  Not "turn it off" (which you can't do anyhow)... but delete it.  And only because of most likely one small error in an "if" statement in some code buried deep in the IBM SSL application code.

Watching them (via desktop sharing) as they second and third guess themselves as they go to delete Certificates or CAs that are expired shows me that SSL and TLS are still very misunderstood...  even by the Digital Certificate Manager (DCM) and the IBM SSL APIs.


Last edited 07/27/2015 at 12:50:30


Copyright 1983-2017 BVSTools
GreenBoard(v3) Powered by the eRPG SDK, MAILTOOL Plus!, GreenTools for Google Apps, jQuery, jQuery UI, BlockUI, CKEditor and running on the IBM i (AKA AS/400, iSeries, System i).