cancel
Showing results for 
Search instead for 
Did you mean: 

handshake_failure when using TLS1.2 to sandbox

We got an email from authorize.net indicating we were not using TLS1.2 and that they would be dropping other suites.  I went to investigate and found we were indeed using TLS1.2.  But when I attempt to connect to the sandbox (test.authorize.net) I get

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

I verified we were using TLS1.2 with "-Djavax.net.debug=all" and made sure we had UnlimitedJCEPolicyJDK7 installed.  I'm running out of ideas.  I inherited this code, and It's not been run against the sandbox since I've been here, so I can't claim there are not other issues.  I'll include the debug log for your reading enjoyment.  Any ideas to further debug?  Is there a server side log someplace?

 

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1544125841 bytes = { 161, 145, 102, 134, 111, 183, 221, 81, 54, 141, 239, 231, 49, 96, 191, 62, 110, 197, 120, 20, 74, 103, 237, 184, 252, 49, 52, 26 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
[write] MD5 and SHA1 hashes:  len = 193
0000: 01 00 00 BD 03 03 5C 09   7E 91 A1 91 66 86 6F B7  ......\.....f.o.
0010: DD 51 36 8D EF E7 31 60   BF 3E 6E C5 78 14 4A 67  .Q6...1`.>n.x.Jg
0020: ED B8 FC 31 34 1A 00 00   38 C0 0A C0 14 00 35 C0  ...14...8.....5.
0030: 05 C0 0F 00 39 00 38 C0   09 C0 13 00 2F C0 04 C0  ....9.8...../...
0040: 0E 00 33 00 32 C0 08 C0   12 00 0A C0 03 C0 0D 00  ..3.2...........
0050: 16 00 13 C0 07 C0 11 00   05 C0 02 C0 0C 00 04 00  ................
0060: FF 01 00 00 5C 00 0A 00   34 00 32 00 17 00 01 00  ....\...4.2.....
0070: 03 00 13 00 15 00 06 00   07 00 09 00 0A 00 18 00  ................
0080: 0B 00 0C 00 19 00 0D 00   0E 00 0F 00 10 00 11 00  ................
0090: 02 00 12 00 04 00 05 00   14 00 08 00 16 00 0B 00  ................
00A0: 02 01 00 00 0D 00 1A 00   18 06 03 06 01 05 03 05  ................
00B0: 01 04 03 04 01 03 03 03   01 02 03 02 01 02 02 01  ................
00C0: 01                                                 .
main, WRITE: TLSv1.2 Handshake, length = 193
[Raw write]: length = 198
0000: 16 03 03 00 C1 01 00 00   BD 03 03 5C 09 7E 91 A1  ...........\....
0010: 91 66 86 6F B7 DD 51 36   8D EF E7 31 60 BF 3E 6E  .f.o..Q6...1`.>n
0020: C5 78 14 4A 67 ED B8 FC   31 34 1A 00 00 38 C0 0A  .x.Jg...14...8..
0030: C0 14 00 35 C0 05 C0 0F   00 39 00 38 C0 09 C0 13  ...5.....9.8....
0040: 00 2F C0 04 C0 0E 00 33   00 32 C0 08 C0 12 00 0A  ./.....3.2......
0050: C0 03 C0 0D 00 16 00 13   C0 07 C0 11 00 05 C0 02  ................
0060: C0 0C 00 04 00 FF 01 00   00 5C 00 0A 00 34 00 32  .........\...4.2
0070: 00 17 00 01 00 03 00 13   00 15 00 06 00 07 00 09  ................
0080: 00 0A 00 18 00 0B 00 0C   00 19 00 0D 00 0E 00 0F  ................
0090: 00 10 00 11 00 02 00 12   00 04 00 05 00 14 00 08  ................
00A0: 00 16 00 0B 00 02 01 00   00 0D 00 1A 00 18 06 03  ................
00B0: 06 01 05 03 05 01 04 03   04 01 03 03 03 01 02 03  ................
00C0: 02 01 02 02 01 01                                  ......
[Raw read]: length = 5
0000: 15 03 03 00 02                                     .....
[Raw read]: length = 2
0000: 02 28                                              .(
main, READ: TLSv1.2 Alert, length = 2
main, RECV TLSv1 ALERT:  fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
wdtj1234
Member
1 ACCEPTED SOLUTION

Accepted Solutions

Finally found an answer.  Apparently Java7 (with UnlimitedJCEPolicyJDK7) has protocols that are not enabled under TLS1.2.  By forcing these to be included, it seems to be working. 

 

To be more specific, I added the code:

        sslSocket.setEnabledCipherSuites(new String [] {
                "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
                "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
                "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
                "TLS_RSA_WITH_AES_128_CBC_SHA",
                "TLS_RSA_WITH_AES_128_CBC_SHA256",
                "TLS_RSA_WITH_AES_256_CBC_SHA256"});

This added the Authorize.net ciphers (as advertized by www.ssllabs.com) minus several that java7 does not support.

 

Thanks everyone for your help.

View solution in original post

3 REPLIES 3

Hello @wdtj1234

 

I'm not an expert here, but a quick peek at your ciphers shows you have quite a few more listed than supported by Authorize.Net.  You can start by checking those supported by Authorize.Net in our FAQ:  https://support.authorize.net/s/article/Authorize-Net-Support-for-SSL-TLS-FAQ

 

 

You can check which ciphers your system support using the URL and a bit of pruning.

 

https://www.ssllabs.com/ssltest/analyze.html?d=yourdomainhere

 

Richard

RichardH
Administrator Administrator
Administrator

Agreed, that is the purpose of the TLS1.2 handshake, to find a set of ciphers that the two sides agree upon.  We are using the standard set of ciphers that come stock with Java 7 + the additional ciphers exposed when applying UnlimitedJCEPolicyJDK7.  This is an industry standard (albit Java7 is out of production). 

Finally found an answer.  Apparently Java7 (with UnlimitedJCEPolicyJDK7) has protocols that are not enabled under TLS1.2.  By forcing these to be included, it seems to be working. 

 

To be more specific, I added the code:

        sslSocket.setEnabledCipherSuites(new String [] {
                "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
                "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
                "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
                "TLS_RSA_WITH_AES_128_CBC_SHA",
                "TLS_RSA_WITH_AES_128_CBC_SHA256",
                "TLS_RSA_WITH_AES_256_CBC_SHA256"});

This added the Authorize.net ciphers (as advertized by www.ssllabs.com) minus several that java7 does not support.

 

Thanks everyone for your help.