可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

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

回答1:

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 .

回答2:

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.