Here are some tips on what to do if the SSL connection to your server just isn't working as it should.

This article reflects the limited knowledge of it's author(s). If you discover anything incorrect when reading this article, you are asked to please either correct the text, or to leave a note in the text stating the problem.

Helpful documents

The SSL topic is a non trivial one. Do try to read and understand the documentation available:

Understanding SSL communications setup

When an SSL communication is being set up, all the phases up to the final data transfer, that is the handshaking and certificate exchanges are done unencrypted. That means they can be examined and thus debugged from the outside of the two communication parties.

Debugging tools

Since, as noted in the last paragraph the setup of the SSL connection is not encrypted, we can sniff the traffic. That can be done with:

Unfortunately the "info" LogLevel is not enough and "debug" is overkill. modssl by Ralf S. Engelschall on which Apache's modssl is based had a "trace" Level, which is still present in Apache's modssl source code. But it is not known how that "trace" log level can be activated from the configuration file.

Making sure that the browser trusts the certificate

Internet Explorer (under Internet Options->Content->Certificates) and Firefox both offer an interface for certificate management. It appears that Firefox will trust a certificate that the user installs even if it can't follow and verify the certificate chain. In contrast Internet Explorer will not trust a certificate where it can't verify the certificate.

Also Internet Explorer has a very comprehensive and well structured certificate management interface, that is helpful for seeing certificate paths and certificate properties.

Unfortunately IE is not helpful at all in its failure mode. When something's wrong, it will not finalize the setup of the SSL connection and not display any useful error. FF instead will at least display a semi useful error. Additionaly, since FF is using the openssl library as its SSL engine, Firefox' error messages correspong to openssl's alert messages.

Manually verifying certificates

You can use the openssl command line tool to do all sorts of certificate manipulation and analysis tasks:

The log entry is only half useful, since first it doesn't say what exactly the reason for the client not accepting the certificate was, and second in this specific case it's missleading, because in fact it was the server that told the client that id wouldn't accept the certificate that the client was presenting to it.

A more specific reason for the communications breakdown can be found in the SSL protocol trace (see the "Debugging tools" section on how to do a trace).

This document explains how to dissect the handshake and how to find the relevant message containing the specific error code. Note that one doesn't need the Microsoft Network Monitor to do the message dissecting: Wireshark works equally well.

The important thing to take away from the the document is that SSL contains an alert protocol, that can be seen and found in the transmitted TCP packets of an SSL communication, that contains an error code specifying the reason why a communication failed to be set up.

As you can see in the screenshot, the two bytes inside the "Alert Message" contain the error code "2f". That error code can be looked up in the respective rfc. In this case it's the code 47 (0x2f), which means "illegal_parameter" - there was some property of the certificate that the server didn't like and refuses to accept. In our case the server was expecting a different issuer CN.