We recently deployed our first app to WebSphere Liberty using Java 17 to one of our test environments. We immediately started facing issues relating to SSL.

java.lang.IllegalArgumentException: Unsupported CipherSuite: SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

As the dev team didn’t face these issues, we focussed on our test environment. The primary focal point being our security hardening baseline. After removing the baseline for enabledCiphers our problems disappeared.

We later discovered that we needed to change the enabledCiphers prefix from SSL_* to TLS_*. After making this change the issue was resolved.

Environment

Diagnosis

Early investigation

To aid with the investigation we installed the adminCenter. This allowed us to test an app that we have regularly used without facing any problems. Luckily, and as expected, the adminCenter encountered the same problem. This confirmed our suspicions that the issue was with one of our configurations. We focussed our attention on our security hardening.

The following snippet shows the SSL settings that work fine with Java 8, but not with Java 17.

<ssl id="defaultSSLConfig"
    sslProtocol="TLSv1.2"
    keyStoreRef="defaultKeyStore"
    enabledCiphers="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_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
/>

As this was the first-time using Java 17 with WebSphere Liberty it seemed there were changes around the SSL Cipher. To test this, we removed the enableCiphers setting after which the SSL issues disappeared. Adding back re-introduced the problem. Rolling back from Java 17 to java 8 had the same effect – the adminCenter worked fine. Removing each cipher one-by-one resulted in the same error, until there were no more ciphers to remove.

Googling didn’t find any useful information to resolve the problem. After a few minutes I gave up and decided to run a trace.

Enabling a trace

To check the internals, the following trace specification was configured in the server.xml file. The issue was replicated, and the trace file analysed.

<logging traceSpecification="SSLChannel=all:com.ibm.ws.ssl.*=all:com.ibm.websphere.ssl=all:com.ibm.wsspi.ssl.*=all" isoDateFormat="true" />

The trace file only displayed the unsupported CipherSuite error. There was still no useful data to work with.

java.lang.IllegalArgumentException: Unsupported CipherSuite: SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

After removing the enabledCiphers keyword, I repeated the successful test and checked the trace.log file. I searched for any CipherSuite messages and voila! The cipher name had changed from an SSL_ prefix to a TLS_ prefix.

getEnabledCipherSuites Entry 
adjustSupportedCiphersToSecurityLevel Entry  
(49) TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ...

Solution

The solution was simply a matter of renaming the cipher to use the TLS_ prefix. In the below example I took the chance to enable TLS 1.3 for my testing and it worked fine.

<ssl id="defaultSSLConfig"
    sslProtocol="TLSv1.2,TLSv1.3"
    keyStoreRef="defaultKeyStore"
    enabledCiphers="TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
/>

DISCLAIMER

The enabledCiphers values were selected for testing purposes only. No recommendation for suitable and secure CipherSuites is inferred in the above example. You always need to consult your security experts and follow their guidance.

Conclusion

I have no idea whether any documentation exists about this change. I’m sure there is. After much googling we came up empty. If I ever find it, I’ll be sure to link it.

I hope this blog not only shows the solution but shows the process we followed to identify and resolve the problem.