Javax Net SSL sslhandshakeexception Received Fatal Alert Handshake_failure

Javax Net SSL sslhandshakeexception Received Fatal Alert Handshake_failure

The notorious Java exception javax.net.ssl. SSLHandshakeException: got fatal alert: handshake failure is difficult for a mere mortal to recognize. What she needs to say is, most definitely, something like this:

Sorry, neither the JVM nor the server supports any of the cryptographic protocols / versions and cypher suites.

For eg, a server needs a higher version of TLS than the (old) JVM support, or needs more cypher suites than the JVM knows. Now you’re going to learn how to figure out what’s going on.

Second, we’ll figure out what both the server and JVM endorse and analyse it to see if they’re not in agreement. Feel free to skip through the outputs and return to them later after they have been explained.

Release

If the HTTPS method (GET, PUT, etc.) or the SOAP API call / request / connexion fails to complete the TLS / SSL handshake with the remote endpoint (or server, in most cases …), the server frequently sends a fatal alert: handshake failure exception with no further indication of the underlying cause. For example, below is a partial Java stack trace of this exception:

Solution for:

1. javax net ssl sslexception unrecognized ssl message plaintext connection
2. javax net ssl sslexception received fatal alert protocol_version
3. javax net ssl sslpeerunverifiedexception
4. java io eofexception ssl peer shut down incorrectly
5. javax net ssl sslhandshakeexception received fatal alert bad_certificate
6. javax net ssl sslexception closing inbound before receiving peer’s close_notify
7. caused by java io eofexception ssl peer shut down incorrectly
8. caused by javax net ssl sslhandshakeexception unsupported curveid 29
9. android javax net ssl sslpeerunverifiedexception no peer certificate
10. javax net ssl sslexception received fatal alert protocol_version fix
11. javax net ssl sslpeerunverifiedexception peer not authenticated httpclient
12. asdm javax net ssl sslhandshakeexception received fatal alert handshake_failure

History

When a TLS client and server (e.g. an API endpoint or resource) first start to communicate, they agree on a protocol version, pick cryptographic algorithms, potentially authenticate each other, and use public-key encryption techniques to create shared secrets.

The TLS Handshake Protocol shall contain the following steps:

• Exchange hello messages to agree on algorithms, exchange random values, and search for resumption of sessions
• Exchange the necessary cryptographic parameters to allow the client and the server to agree on a hidden premaster.
• Exchange certificates and cryptographic details to allow the client and the server to authenticate themselves
• Generate a master secret from a premaster secret and exchange random values
  Provide the protection parameters for the record layer
• Enable the client and server to check that their peer has determined the same security parameters and that the handshake has occurred without tampering with the intruder.

The handshake protocol can be summarized as follows: the client sends a ClientHello message to which the server must respond with a ServerHello message, or else a fatal error occurs and the connexion fails. ClientHello and ServerHello are used to provide security enhancement functionality between the client and the server. The following attributes are set by ClientHello and ServerHello: Protocol Edition, Session ID, Cipher Suite, and Compression Process. In addition , two random values are generated and exchanged: ClientHello.random and ServerHello.random.

Handshake failure can occur due to a variety of reasons listed below. Note: you need to examine each of them (or all of them) to see what the problem you are most likely to be experiencing is.

1. Cipher Mismatch: Incompatible cypher suites used by the client and the server. This would require the client to use (or enable) a cypher suite provided by the server.
2. Protocol Mismatch: Incompatible versions of SSL in use (e.g. only TLS v1.2 can be allowed by the server, while only TLSv1 can be used by the client). Most frequently, the client may need to ensure that it uses a compatible version of the SSL / TLS protocol approved by the server.
3. Incorrect or incomplete Certificate or Certificate Chain: Incomplete server certificate trust path; the server certificate can not be trusted by the client. This will normally result in a more verbose error (PKIX Exception), but very little information can be provided. Usually, the workaround is to import the server’s CA certificate to the client’s trust shop.
4. Hostname Mismatch: The certificate is issued for another domain. Again, this case may result in a more verbose post. In this case, the server will be modified to use the right certificate
5. SNI Enabled Server: Incompatible service options, such as the Domain Name Indication (SNI) needed for server access or not supported by the domain.