Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The "DebuggingSSLProblems" page has been changed by TomasPospisek: http://wiki.apache.org/httpd/DebuggingSSLProblems?action=diff&rev1=9&rev2=10 Comment: fix wording and syntax == Understanding SSL communications setup == - [[The http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html|SSL/TLS Strong Encryption: An Introduction]] provides some intermediate level on how SSL communication works - in particular the paragraph [[http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html#ssl|Secure Sockets Layer (SSL)]]. + [[The http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html|SSL/TLS Strong Encryption: An Introduction]] provides some intermediate level information on how SSL communication works, particularily the paragraph [[http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html#ssl|Secure Sockets Layer (SSL)]]. 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. @@ -50, +50 @@ * [[http://www.wireshark.org/|Wireshark]] or * [[http://www.microsoft.com/download/en/details.aspx?id=4865|Microsoft Network Monitor]](runs on Windows only) - * the [[http://www.openssl.org/|openssl]] command line tool which both include SSL protocol dissectors, and thus are able to decode and display SSL handshakes in a human understandable format. @@ -58, +57 @@ If you need to analyse traffic that is happening during the data transfer phase, then you'll need [[http://www.thoughtcrime.org/software/sslsniff/|sslsniff]] which is able to decode traffic when given the apropriate certificate keys. + Certificates can be analyzed with the + + * [[http://www.openssl.org/|openssl]] command line tool == Enable SSL logging == @@ -128, +130 @@ [Thu Oct 06 16:39:06 2011] [error] Re-negotiation handshake failed: Not accepted by client!? }}} - That is only half-way useful, since first it doesn't say what exactly was the reason that the client didn't accept the certificate 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. + 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). [[http://blogs.msdn.com/b/sudeepg/archive/2009/02/16/debugging-ssl-handshake-failure-using-network-monitor-a-scenario.aspx|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 [[http://blogs.msdn.com/b/sudeepg/archive/2009/02/16/debugging-ssl-handshake-failure-using-network-monitor-a-scenario.aspx|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 containing the reason why a communication failed to be set up. + The important thing to take away from the [[http://blogs.msdn.com/b/sudeepg/archive/2009/02/16/debugging-ssl-handshake-failure-using-network-monitor-a-scenario.aspx|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. {{http://tpo.sourcepole.ch/opaque/wireshark-https.png|Wireshark screenshot}} - As you can see in the screenshot, the two bytes contained in the "Alert Message" contain the error code "2f", which can be looked up in the respective [[http://tools.ietf.org/html/rfc2246#section-7.2|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. + 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 [[http://tools.ietf.org/html/rfc2246#section-7.2|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. --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
