If you use Open Liberty Java Application Server, you should be careful when maintaining a cipher list. See what happens if you are not careful.
<ssl id="my_tls_settings"
securityLevel="CUSTOM"
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_DHE_RSA_WITH_AES_256_GCM_SHA384 SSL_DHE_DSS_WITH_AES_256_GCM_SHA384 SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL_DHE_RSA_WITH_AES_128_GCM_SHA256 SSL_DHE_DSS_WITH_AES_128_GCM_SHA256"
sslProtocol="TLSv1.2"
/>Now, that is not an uncommon SSL TLS configuration. You might want to add chacha20-poly ciphers, depending on your use cases. But this actually will make any application unable to create outbound connections. Any.
Why, you might ask?
Well, because two of those ciphers are separated using two spaces (instead of one). This took us a while. We did not expect a configuration error, because we also had set Liberty to not start when there is a configuration error:
<config onError="fail" />Well, it did start, but there was no common cipher. Whut? Those are perfectly fine, and using testssl.sh I verified the target would also support some of the above. So what was wrong?
Well, luckily there is good documentation on how to debug ssl/tls connections over at IBM. You basically just need to add this line to your server.xml:
<logging traceSpecification="SSLChannel=all:com.ibm.ws.ssl.*=all:com.ibm.websphere.ssl=all:com.ibm.wsspi.ssl.*=all" isoDateFormat="true" />You will now get an additional trace.log file on your logs folder. It revealed that the cipher TLS_NULL_NULL_NULL was chosen by the application, and none was available. Huh?
In the end it was just guesswork. I found the space by accident, removed it, and the application started to work again.
I opened a bug report over at github.com/OpenLiberty. Let’s see what they make from it. Not being able to parse multiple separator chars seems a little anachronistic today.