Gerard van der Maaden

SoapUI is one of the best free tools around to test web services. Some time ago I was trying to send a soap message towards a SSL web service that was set up for client certificate authentication. I pretty soon got stuck at the “javax.net.ssl.SSLException: HelloRequest followed by an unexpected handshake message” error, but after reading several posts on the internet I solved that issue. It’s not really that complicated after all, but since I could not find a decent place on the internet that explains this scenario in a proper way, here’s a list of steps that you need to do to make it work.

Note: this following steps are based on a Windows environment

Step one:

Export your certificate (the one that you want to use as the client certificate) using the export wizard with the private key and with all certificates in the certification path:

Give it a password (anything you want):

And export it as a PFX file to a location somewhere on disk:

Step two:

Install the newest version of SOAP UI (currently it is 3.6.1)

Open the file C:\Program Files\eviware\soapUI-3.6.1\bin\ soapUI-3.6.1.vmoptions and add this line at the bottom:

-Dsun.security.ssl.allowUnsafeRenegotiation=true

This is needed because of a JAVA security feature in their newest frameworks (For further reading about this issue, read this: http://www.soapui.org/forum/viewtopic.php?t=4089 and this: http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html).

Open SOAPUI and go to preferences>SSL Settings and configure your certificate in the keystore (use the same password as in step one):

That should be it. Just create a new project and import the WSDL from the client authenticated SSL webservice:

And now you should be able to send soap messages with client certificate authentication.

The above steps worked for me, but please drop a note if it does not work for you.

Recently I was working on a BizTalk project that included a secured (SSL) SOAP connection using a WCF-Custom send port that was pointing to the partner’s endpoint. Our send port raised an interesting exception when sending a test message to our partner:

A message sent to adapter "WCF-Custom" on send port "<SEND PORT NAME>" with URI "<PARTNER’S URL>" is suspended.
Error details: System.ServiceModel.CommunicationException: An error occurred while making the HTTP request to <PARTNER’S URL>. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.

After several hours of analysis (with the aid of some network sniffing tools) we found out that our partner was not accepting TLS 1.0 as the security protocol. Great, now what?

It seems that BizTalk (and I suppose all other .Net based solutions) executes the SSL handshakes in some sequential steps:

1. The BizTalk send port connects to the remote endpoint using the security protocol TLS 1.0
2. If the endpoint denies the TLS 1.0 request, BizTalk will try to use the security protocol SSL3
3. If the endpoint accepts this, the security protocol is agreed and the connection is established.

In some occasions, when the remote system does not support TLS 1.0, it could be that the remote system immediately terminates the connection after the first step. After that BizTalk raises the error mentioned above because it expects a proper answer from the remote system (that should state that the SSL type is not supported).

The details in the error makes sense though (especially the “Received an unexpected EOF or 0 bytes from the transport stream” part): BizTalk expects an incoming stream containing the response of the SSL request, but doesn’t receive it because the remote system immediately terminates the connection after the first TLS 1.0 request.

The solution is simple: you need to override the default SSL handshake of your WCF-Custom send port by creating your own WCF custom behavior that implements the IEndpointBehavior interface.

There is actually only one line of code needed in the ApplyClientBehavior method of your custom ServiceBehavior class (which should implement the IEndpointBehavior interface) where you set the System.Net.ServicePointManager.SecurityProtocol to System.Net.SecurityProtocolType.Ssl3:

And that does the trick: BizTalk will now initialize the SSL connection using SSL3 and it will avoid using TLS 1.0

More information about developing your own WCF behavior: http://msdn.microsoft.com/en-us/library/dd203050(BTS.10).aspx (scroll down to the Enabling Custom Behaviors and Configuring a Custom Behavior chapters, which includes a good explanation of a custom behavior that implements the IEndpointBehavior).