IBM HTTP Server - SSL Handshake Failed and why it matters to keep a backup of the key ring file
Thomas Hampel
20 September 2014All of a sudden (as usual) clients started to receive SSL expiration warnings when accessing the customer's Connections environment.
A quick look into the log file /opt/IBM/HTTPServer/logs/error.log confirmed the SSL certificate has expired.:
[Sat Sep 20 22:21:05 2014] [error] [client 10.175.198.62] [8222a80] [30015] SSL0221E: SSL Handshake Failed, Either the certificate has expired or the system clock is incorrect. [10.175.198.62:40028 -> 10.175.220.11:443] [22:31:05.000019743]
Opening the *.kdb file with the gsktool showed the default certificate had expired.
Ok, nothing easier than that... so lets create a new signing request and get this signed by the certificate authority.
Once that is completed we can import the new certificate incl. any trusted roots quickly.
However when you try to import/receive your signed certificate keep the following in mind:
- You can only import a signed certificate into >exactly< the same *.kdb file which was used to create the certificate request.
Within the iKeyman utility, switch from "Personal certificates" to "Personal Certificate Requests" (sorry, only got screenshots in German available and hope the translation is correct)
normally it would look like this...
but if it looks like the following screenshot, then bad luck... you can not import your signed certificate anymore.
Instead you'll see "The certificate request created for the certificate is not in the key database" / "Die für das Zertifikat erstellte Zertifikatsanforderung ist nicht in der Schlüsseldatenbank vorhanden."
Now your options to solve this are:
a) find the original key ring file (*.kdb) which was used to create the certificate request
b) create a new certificate request, but this time make sure to keep the *.kdb file
c) set up a self signed certificate - although this is an option, it should not be considered
d) update the SSL directives on your IBM HTTP Server and set SSLClientAuth to "noverify". This will not fix the problem but will at least allow the server to be up and running with an expired certificate until you have obtained a new one.
(...if there are other options, please let me know)
Lessons learned:
- Keep the key ring file backed up
- Track certificate expiration time
- When expired, take action well in advance
- Even when delegating simple work, supply detailled instructions on least 250 pages
Off topic:
Why do I need to troubleshoot such a very very basic problem myself on a Saturday night?
Further reading: