Handshake process of SSL/TLS and javax.net.ssl.SSLHandshakeException:Received fatal alert:handshake_failure anomaly __.net

I. The handshake process of SSL/TLS

In the SSL/TLS handshake process, the client and the server need to exchange parameters, the specific process is as follows: The client provides the various cipher suites that it supports (including cryptographic algorithms and hash functions) from which the server chooses itself and supports cipher Suiteand notifies the client that both will be used for this data transfer server simultaneously sends its own digital certificate (including the server name, CA, and public key) as an identifier to the client client to confirm the validity of the server's digital certificate to the CA Client-generated session key (subsequent data transfer between the client and server will use this session key) to send to the server using the server's public key encryption session key or the client can also use the DH key exchange

Two. Handshake_failure Anomaly analysis

The following exceptions often occur during SSL/TLS communication between the client and the server:

Javax.net.ssl.SSLHandshakeException:Received Fatal Alert:handshake_failure

First, the timing of the exception occurs when the client and the server are handshake, and the effective data transfer between the client and the server has not yet begun.

Reason one: In view of the above handshake process, this anomaly often occurs in the 4th step, that is, when the client obtains the server digital certificate, verifies the certificate validity to the CA.

When the client tries to authenticate to a trusted CA, it discovers that the CA referenced by the server's digital certificate does not appear in the client's Trust store.

Reason two: Additionally, the exception may be due to inconsistent ssl/tls versions used by the client and the server. The server uses a high version of TLS, while the client-supported TLS version is low.

At this point, you can set the JVM parameters for the client to improve the TLS version of the client:

-dhttps.protocols=tlsv1.2,tlsv1.1,tlsv1.0,sslv3,sslv2hello

Both of these reasons can be resolved by upgrading JDK to 1.8. Java 8 supports the TLSv1.2 version by default.