Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The "ScratchPad" page has been changed by TomasPospisek: http://wiki.apache.org/httpd/ScratchPad?action=diff&rev1=2&rev2=3 Comment: working on the "debugging SSL" article = Writing space for new content = + = Debugging SSL Problems = @@ -8, +9 @@ 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: + + * [[http://httpd.apache.org/docs/trunk/ssl/|Apache SSL/TLS encryption documentation]] + * [[http://www.openssl.org/docs/|Openssl documentation]] + * [[http://tools.ietf.org/html/rfc2246#section-7.2|SSL alert messages]] + + Make sure you are following the howtos very closely and you do understand what they are doing. Even small SSL missconfigurations can prevent completely your server from communicating with clients. + + == Understanding modssl's components == Modssl does not implement the SSL protocol. It uses the [[http://www.openssl.org/|openssl]] library to do the SSL negotiation, handshaking and encoding into the SSL protocol. - That has the implication that if you need to debug what's happening during a connection you'll need to read openssl's documentation. + That has the implication that if you need to debug what's happening during a connection you'll need to read [[http://www.openssl.org/docs/|openssl's documentation]]. However the configuration of the handshake phase, that is: @@ -31, +44 @@ 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: @@ -40, +54 @@ which both include SSL protocol dissectors, and thus are able to decode and display SSL handshakes in a human understandable format. + If you have to [[http://www.bonsai.com/wiki/howtos/debugging/tcpdump_wireshark/|transfer]] transfer traffic seen on a server to your own machine for local analysis, then you can use [[http://www.tcpdump.org/|tcpdump]]. + 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. + == Enable SSL logging == @@ -57, +74 @@ * http://httpd.apache.org/docs/trunk/ssl/ssl_howto.html#logging * http://httpd.apache.org/docs/trunk/mod/core.html#loglevel - Unfortunately the "info" LogLevel is not enough and "debug" is overkill. [[http://www.modssl.org/|modssl by Ralf S. Engelschall]] on which Apache's modssl is based had a [[http://www.modssl.org/docs/2.7/ssl_reference.html#ToC20|"trace"]] Level, which is [[http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?revision=1180329&view=markup|still]] present in Apache's modsll source code. But it is not known how that "trace" log level can be activated from the configuration file. + Unfortunately the "info" LogLevel is not enough and "debug" is overkill. [[http://www.modssl.org/|modssl by Ralf S. Engelschall]] on which Apache's modssl is based had a [[http://www.modssl.org/docs/2.7/ssl_reference.html#ToC20|"trace"]] Level, which is [[http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?revision=1180329&view=markup|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. + --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
