Ever had to troubleshoot an SSL connection issue but overwhelmed by a “je ne sais quoi” feeling ? Let me try to ease your pain based on recent experience.
Use case :
- Integration Server acts as an ssl client, connecting to a partner’s HTTPs server
- Certificates are exchanged and loaded in key- and truststore on both ends
- Calling the URL over HTTPs results in error “ssl handshake failure”.
Our first step, enable ssl debugging on the Integration Server.
Introduce two extended settings (“watt.net.ssl.debug=true” and “watt.ssl.iaik.debug=true”) and restart the Integration Server. Per default ssl debug information will be send to the standard out.
After calling the URL again over HTTPs additional debug information shows:
ssl_debug(2): Starting handshake (iSaSiLk 3.03)… ssl_debug(2): Remote client:18.104.22.168:8443, Timestamp:Wed Aug 06 14:31:05 CEST 2014 ssl_debug(2): Sending secure renegotiation cipher suite ssl_debug(2): Sending v2 client_hello message, requesting version 3.1… ssl_debug(2): Received alert message: Alert Fatal: handshake failure ssl_debug(2): SSLException while handshaking: Peer sent alert: Alert Fatal: handshake failure ssl_debug(2): Shutting down SSL layer… ssl_debug(2): Closing transport…
What are these log entries telling us ?
The Integration Server is sending message “Sending v2 client_hello” to the HTTPs server. This request is immediately rejected by the end target (ref entry “Received alert message: Alert Fatal: handshake failure” reported in ssl debug log lines).
The purpose of the SSL v2 Client Hello is listed in the TLS specification as a way for SSL Clients to allow backwards compatibility with previous versions of SSL. The specification also states that TLS Servers are allowed to reject SSL v2 Client Hello messages if they do not support the previous versions of SSL.
Per default the Integration Server can handle different cryptographic protocols (tls, sslv2, sslv3). How to discover what type of protocol the HTTPs server supports?
- Go to www.openssl.org
- Download and install the binary distribution of your preference
- Running following commands :
- to verify is HTTPs server support tls1
openssl s_client -verify 6 -state -msg -tls1 -showcerts -connect <host>:<port>
- to verify is HTTPs server support ssl2
openssl s_client -verify 6 -state -msg -ssl2 -showcerts -connect <host>:<port>
- to verify is HTTPs server support ssl3
openssl s_client -verify 6 -state -msg -ssl3 -showcerts -connect <host>:<port>
Note : Replace “<host>:<port>” with the hostname and port of your end target specifications.
If the result contains “ssl handshake failure” it indicates your target is rejecting the selected protocol.
In our use case the partner only accepted tls. The issue was solved once the administrator of the HTTPs server enabled ssl v3 on his end.
Author: Johan De Wulf