0

We have configure a Big F5 load balancer virtual server for a particular IP address which redirects incoming https requests to several Windows servers where there is functionality to generate responses.

I am using SoapUI to test access to these windows servers via the IP address of virtual server in the Big F5.

Using Server and Client certificates generated by the organization where the we have also this set up and sending requests via SoapUI I get the predicted responses back.

The business requirements call for Commercially signed certificates by Thawte.

We created a Certifcate Servcice Request (CSR) to generate a Server certificate and its private key and then we had it signed by Thawte, and also requested a Client Commercially signed certificate from Thawte.

We loaded both certificates in SoapUI client and the Big F5 load balancer but we attempting to test the requests we get the "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" error.

My questions are: How can I monitor where exactly the 2 way SSL handshake is terminated The actual reason what exactly is happening?.. why using commercially signed certificates this does not work now?

Any replies are welcome. Thanks.

However when we swithch Serverto commercially signed by Thawte

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98
user1015715
  • 11
  • 1
  • 2
  • 4
  • You would have to look at the remote host's log in detail, but maybe you are talking SSL to a plaintext port. It would be useful to edit the output of running the client with -Djavax.net.debug=ssl,handshake into your question. – user207421 Aug 16 '12 at 05:13
  • Thanks Peter for the reply. The client is a SoapUI request that has not changed except a different client certificate, the server is a virtual server configured in a F5 load balancer which also has not changed except with a new server certificate signed by the same CA that signed the client certificate in the SoapUI project request. – user1015715 Aug 16 '12 at 07:42

3 Answers3

0

This is possibly due to the Java security feature. If so you need to edit the soapui-4.x.x.vmoptions file located at soapui-4.x.x\bin folder and add -Dsun.security.ssl.allowUnsafeRenegotiation=true to the end.

You may also need to export the certificate as a pfx file and set it up in soapUI preference page. For details you can check http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx and http://forums.devarticles.com/java-development-38/javax-net-ssl-sslhandshakeexception-received-fatal-alert-handshake-failure-11809.html .

CS Pei
  • 10,869
  • 1
  • 27
  • 46
0

The client is a SoapUI request that has not changed except a different client certificate

That suggests that the server doesn't trust the new client certificate, which in turn implies that the client certificate wasn't even sent because it wasn't signed by one of the server's trusted signers. Closing the connection is the server's only real option in this circumstance, as there isn't an SSL alert for it.

user207421
  • 305,947
  • 44
  • 307
  • 483
-1

Make sure you have address translation on and the SNAt set to Auto Map for your VIP

David
  • 1