To get more specific information on what is causing the handshake failure, we need to collect more information regarding the SSL handshake failure.
In the DevTest Workstation, under Help menu there is a HTTP/SSL Debug viewer that lets we observe the details of HTTP and SSL activity in DevTest Workstation. This feature can be helpful in performing diagnostics.
To access HTTPS and SSL Debug Viewer documentation, please take a look at the following link: https://docops.ca.com/devtest-solutions/10-4/en/using/using-ca-application-test/using-devtest-workstation-with-ca-application-test/running-test-cases-and-suites/http-and-ssl-debug-viewer/
One of the common causes for the handshake failure, is when the client application (DevTest Workstation) sends a request using a TLS version that is not supported by the server.
Example, DevTest Workstation uses TLSv1 and the Server does not accept it.
In this case, we will see something like
*** ClientHello, TLSv1
And after few lines you see a TLSv... fatal alert, it can be that the Client Hello is being executed with a TLS version not supported by the server.
In this case, we need to update the local.properties with the following property:
for TLS version 1.2:
for TLS version 1.1:
Save the properties files and restart the Workstation.
We have seen some issues when the SSLv3 and SSLv2Hello are also set with the https.protocols property -
Looking at the HTTP/SSL Debug information we could see the SSL handshake was failing right after the ClientHello. The Workstation was using TLSv1.2.
The ServerHello was not happening - it could not find an acceptable set of algorithms and we got a handshake failure alert - https://tools.ietf.org/html/rfc5246#section-220.127.116.11
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
The https.protocols property was set to TLSv1.2,TLSv1.1,TLSv1,SSLv3,SSLv2Hello, like https.protocols= TLSv1.2,TLSv1.1,TLSv1,SSLv3,SSLv2Hello
The options SSLv3 and SSLv2Hello were removed from the properties file and the Workstation restarted.
After this modification we were able to get a successful response from the endpoint.
If we see the server is requesting a certificate, CertificateRequest, and the Workstation is not providing the client authentication, for the REST step we will need to provide the client keystore in the local.properties under the four properties below:
ssl.client.cert.path=[path to your keystore ]……… [path usage : ‘ / ‘ not backward. ex: c:/mykeystore.jks]
ssl.client.cert.pass=[your keystore password]
ssl.client.key.pass=[password for the key entry if using JKS keystore and key has a different password from keystore]
ssl.client.alias=[alias to use]
Save the properties file and restart the Workstation.