Tuesday, August 26, 2014

How to troubleshoot an SSL connection issue on webMethods v8.2 Integration Server

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:193.2.253.29: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?
  1. Go to www.openssl.org
  2. Download and install the binary distribution of your preference
  3. Running following commands :
  4. to verify is HTTPs server support tls1
    openssl s_client -verify 6 -state -msg -tls1 -showcerts -connect <host>:<port>
  5. to verify is HTTPs server support ssl2
    openssl s_client -verify 6 -state -msg -ssl2 -showcerts -connect <host>:<port>
  6. 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
Posted by i8c at 10:30 AM
Labels: ,

2 comments:

  1. UnknownNovember 19, 2014 at 2:43 PM

    Hi Johan

    We are facing a similar issue where the HTTPS server is configured with TLS and we are continuously getting these handshake errors. Instead of the partner reverting to sslv3 is there any way to make changes in webMethods so that we can send TLS messages to the partner. We are using IS 7.1.3 and Windows 2008 R2 64 bit.

    Thanks and Regards
    Kunal Dey

    ReplyDelete
  2. i8cDecember 4, 2014 at 11:34 AM

    Hi Kunal

    The fact that an enterprise is moving away from SSLv3 and to TLS probably finds its origin in the POODLE vulnerability that was recently discovered.

    My personal baseline is a webMethods v8.2.x IS but you could try with following IS extended settings
    watt.net.ssl.client.handshake.minVersion= sslv3
    watt.net.ssl.client.handshake.maxVersion=tls

    Regards,

    Johan

    ReplyDelete

Subscribe to: Post Comments (Atom)