How to check what SSL/TLS cipher suites are supported by RestAssured v2.8.0 ?

[Suraj Kelkar]

Hi All,

I am trying to use reastassued v 1.8.0 to auotmate Amazon Webservice API and getting javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure ERROR.
wHEN i LOGGED AWS support team the support guy asked me to check what SSL/TLS cipher suites are supported by RestAssured v2.8.0 ?

Below is his reply -

I understand you're attempting to make an API call into your API Gateway endpoint using RESTAssured's framework, but you're getting SSLHandshakeException errors. One of the things you can check is how the RESTAssured framework handles the SSL certificate coming back from AWS. For example, I ran a quick curl command with extra verbose output to check the TLS version, and other details: $ curl https://drhoe6a8tk.execute-api.us-east-1.amazonaws.com/dev/api/strategists -vvv * Trying 52.84.125.185... * TCP_NODELAY set * Connected to drhoe6a8tk.execute-api.us-east-1.amazonaws.com (52.84.125.185) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: *.execute-api.us-east-1.amazonaws.com * Server certificate: Symantec Class 3 Secure Server CA - G4 * Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5 > GET /dev/api/strategists HTTP/1.1 > Host: drhoe6a8tk.execute-api.us-east-1.amazonaws.com > User-Agent: curl/7.54.0 > Accept: */* As you might notice from the headers above note that this is a TLS 1.2 connection using SHA256. You might want to check that this TLS version is handled by your specific client. Some other possible causes include: - Incompatible cipher suites in use by the client and the server. This would require the client to use (or enable) a cipher suite that is supported by the server. - Incompatible versions of SSL in use (the server might accept only TLS v1, while the client is capable of only using SSL v3). Again, the client might have to ensure that it uses a compatible version of the SSL/TLS protocol. - Incomplete trust path for the server certificate; the server's certificate is probably not trusted by the client. This would usually result in a more verbose error, but it is quite possible. Usually the fix is to import the server's CA certificate into the client's trust store. - The cerificate is issued for a different domain. Again, this would have resulted in a more verbose message, but I'll state the fix here in case this is the cause. The resolution in this case would be get the server (it does not appear to be yours) to use the correct certificate. I sourced the above from this stackoverflow.com post (https://stackoverflow.com/questions/6353849/received-fatal-alert-handshake-failure-through-sslhandshakeexception) Let us know if you can generate a debug-level log of your exact error generated by your client so that it can be determined what compatibility issues might there be during the SSL/Certificate exchange.

-Suraj