Last Friday 5/14 I was able to connect to our TSTDRV account(s) using Java 7; as of Monday I keep getting javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure Turing up logs it looks like we are using TLS1.2 and the client / server have the same cipher. Any idea what I could be overlooking?

*** ClientHello, TLSv1.2
RandomCookie:  
GMT: 1604670312 

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]

*** ServerHello, TLSv1.2
RandomCookie:  
GMT: -1978474041 

Session ID:  
{80, 27, 196, 177, 11, 254, 87, 106, 130, 222, 42, 165, 245, 186, 20, 185, 96, 28, 135, 248, 232, 12, 18, 14, 17, 253, 159, 16, 65, 19, 143, 126}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension server_name, server_name: 
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
***
%% Initialized:  [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]

not that i really would want to debug it, you probably want to check that the ssl certificate trust path is correct

Thanks, I’ll look into that

Starting this morning, we are seeing the exact same errors with a Java 1.8.0_31 and one of our sandboxes (thankfully not in production). Updating to Java 1.8.0_222 works, getting rid of the error, unfortunately we have some other issues preventing us from making that change.

After a bit of poking around It looks like the TSTDRV accounts now support only a subset of the ciphers available to production NetSuite accounts.

how strange is that

We have determined that we need to upgrade to Java 8u141 at a minimum in order to avoid this error. Not sure what changed with that version, but using that version or higher eliminates the SSL exception for us.

thats the version when lets encrypt was added to root CAs

I was searching and digging around, and finally got a few lines of code to reproduce the issue. It has nothing to do with certs, BTW, but is just a bug or bad behavior in older versions of Java (prior to 8u141 b08) as described here https://bugs.openjdk.java.net/browse/JDK-8144566 and here https://bugs.openjdk.java.net/browse/JDK-8181791 I created a test Suitelet, making it available externally, then tried to hit them using this code. The calls fail to some accounts, but not to others.

The response I received from NetSuite support was that the CBC ciphers were insecure and they were doing away with them. If you run a SSL scan on the TSTDRV and Sandbox server URL’s; it shows ciphers which are not supported in Java 7 or Java 7 (JCE) Unlimited Strength Policy files. However, the same scan on a production URL shows the old ciphers are still in place (for now). https://www.ssllabs.com/ssltest/index.html

To help you discover potential failures for related NetSuite services in production accounts, we have scheduled a test window for each of related services with exception for Commerce which should start by June 15, 2021. By July 15, NetSuite will end their support for CBC Ciphers that are not included in this SuiteAnswers Article:

Supported TLS Protocol and Cipher Suites