Skip to content

OpenLiberty: Carefully maintain your ciphers list!

If you use OpenLiberty 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"

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 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="**=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 Let’s see what they make from it. Not being able to parse multiple separator chars seems a little anachronistic today.

Published insoftware showcase

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *