TLSv1.2 ALERT: fatal, handshake_failure

Question

For development purpose, I'm trying to run a small application through a JUnit to invoke a web service in https but I'm stuck in a problem, probably related to the TLS protocol. I've added all the certificates to my truststore, and the following VM arguments to force the TLS 1.2 protocol:

-Djavax.net.debug=ssl:handshake
-Dcom.ibm.jsse2.overrideDefaultTLS=true
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv12
-Djdk.tls.client.protocols=TLSv1.2
-Dhttps.protocols=TLSv1.2

but it seems, somehow, when i call the webservice the protocols is still setted to TLSv1 and that's probably the reason why I receive an handshake failure.

The weird aspect is that when I run the application where is installed I've no problem and I received the expected response.

Am im missing/doing wrong something in the VM arguments? Do I need to set any system property? Any tip? Thanks in advance!

Here some useful info:

SETTINGS:

Enabled protocols: TLSv1.2
Java version: 1.8.0_271 
cipher suites: [TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384, SSL_RSA_WITH_AES_256_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384, SSL_DHE_RSA_WITH_AES_256_CBC_SHA256, SSL_DHE_DSS_WITH_AES_256_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_RSA_WITH_AES_128_CBC_SHA256, SSL_DHE_DSS_WITH_AES_128_CBC_SHA256, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384, SSL_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ECDH_RSA_WITH_AES_256_GCM_SHA384, SSL_DHE_DSS_WITH_AES_256_GCM_SHA384, SSL_DHE_RSA_WITH_AES_256_GCM_SHA384, SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, SSL_RSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ECDH_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_RSA_WITH_AES_128_GCM_SHA256, SSL_DHE_DSS_WITH_AES_128_GCM_SHA256, SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA]

JUNIT LOGS:

SSLContextImpl:  Using X509ExtendedKeyManager com.ibm.jsse2.az
SSLContextImpl:  Using X509TrustManager com.ibm.jsse2.aD
JsseJCE:  Using SecureRandom SHA2DRBG from provider IBMJCE version 1.8
trigger seeding of SecureRandom
done seeding SecureRandom
IBMJSSE2 will enable CBC protection
JsseJCE:  Using SecureRandom SHA2DRBG from provider IBMJCE version 1.8
%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
JsseJCE:  Using signature SHA1withECDSA from provider TBD via init  
JsseJCE:  Using signature NONEwithECDSA from provider TBD via init 
JsseJCE:  Using KeyAgreement ECDH from provider IBMJCE version 1.8
JsseJCE:  Using KeyFactory EC from provider IBMJCE version 1.8
JsseJCE:  Using KeyPairGenerator EC from provider TBD via init 
JsseJCE:  Using cipher AES/GCM/NoPadding from provider TBD via init 
CipherBox:  Using cipher AES/GCM/NoPadding from provider from init IBMJCE version 1.8
JsseJCE:  Using cipher AES/CBC/NoPadding from provider TBD via init 
CipherBox:  Using cipher AES/CBC/NoPadding from provider from init IBMJCE version 1.8 

%% Initialized:  [Session-2, SSL_NULL_WITH_NULL_NULL]
.
.
.
.
 
*** ClientHello, TLSv1
RandomCookie:  GMT: 1648991114 bytes = { 105, 84, 169, 227, 49, 253, 152, 119, 195, 240, 54, 82, 152, 64, 222, 179, 177, 53, 205, 156, 219, 205, 43, 102, 156, 249, 140, 178 }
Session ID:  {} 
Cipher Suites: [SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA, SSL_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_128_CBC_SHA, SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_ECDH_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA] 
 
Compression Methods:  { 0 }
Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension extended_master_secret
Extension server_name, server_name: [type=host_name (0), value=mywebservice.com]

***
P=873286:O=0:CT, WRITE: TLSv1 Handshake, length = 152
P=873286:O=0:CT, READ: TLSv1 Alert, length = 2
P=873286:O=0:CT, RECV TLSv1.2 ALERT:  fatal, handshake_failure
P=873286:O=0:CT, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure
P=873286:O=0:CT, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure

Try running `openssl s_client -connect SERVER_NAME:SSL-PORT` and check what it is telling you about the server supported protocols. For instance `www.google.com:443` will as expected tell you it supports the latest 1.3: `New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384` — Bruno Grieder, Apr 04 '22 at 09:52
Hi @BrunoGrieder I did what you said and that's what I've got `C:\windows\system32>openssl s_client -connect mywebservice.com:443 Loading 'screen' into random state - done CONNECTED(000001A4) 5052:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:455: ` — aramone, Apr 04 '22 at 10:09
Ouch. I know some versions of Windows openssl have issues. Try yours on google.com. Anyway SSL23: that sounds old... Most of these versions have been disabled due to security reasons. Client and server should now be supporting TLS v1.1 minimum (1.3 is even better). Do you know what your server supports ? — Bruno Grieder, Apr 04 '22 at 12:06
@BrunoGrieder I did a try with google and I've got a different error, `connect: The handle is invalid. connect:errno=10060` How can I check what the server support? I think I should force somehow the local client that I run through the jUnit to use the TLS 1.2: Even if I force the execution to use TLS 1.2, it seems to always run with TLS 1, that's why i probably get the handshake failure. That's my guess. Could makes sense? — aramone, Apr 05 '22 at 10:23
You tried `www.google.com:443` ? Your server likely does not support TLS v1.2 — Bruno Grieder, Apr 05 '22 at 15:15

TLSv1.2 ALERT: fatal, handshake_failure

0 Answers0