should be all of them), add SSLabs blog in your RSS reader to keep up to date with the latest security best-practices, and check your websites against their test suite on a regular basis. During our last test I found out that one Tomcat server might soon get a C. Here I describe the steps to ensure the best possible setup that can still give you an A. " />

Getting A on SSLLabs with Tomcat

If you manage any web-servers that host HTTPS content (which should be all of them), add SSLabs blog in your RSS reader to keep up to date with the latest security best-practices, and check your websites against their test suite on a regular basis. During our last test I found out that one Tomcat server might soon get a C. Here I describe the steps to ensure the best possible setup that can still give you an A.

If you’re lucky, you will be using the latest versions of both Java and Tomcat, but more likely you’ll be stuck with some specific versions that hold everything together. Luckily, even older versions are still able to get you the coveted A. There are three main factors that can cost you the green mark – protocols, ciphers and server-preferred order. I’ll go over each of them:

Protocols

Given all the publicity at the end of 2014 regarding POODLE, you’re very likely to have SSLv3 disabled. But if you don’t you should just do it already with sslEnabledProtocols or consider upgrading to latest Java, which will do it by default.

Ciphers

The main part of the setup. Java came with reasonable cipher out of the box at the time, but with all the constant exploit findings for older encryption methods, you need to use the latest version in order to be sure it will keep you safe without manual intervention. And as we all know, production servers lags behind with updates, sometimes considerably. So after some testing I found those ciphers to do the job for now in Java 8, without the need to overwrite JCE policy:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA

Fourth and fifth can be removed and still get A on the test, but I’ve kept them for completeness. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA is also a possibility that does not give you a penalty if used, but 3DES is on it’s way out so why risking it.

There are no ECDSA ciphers due to the limited CA support, but if you happen to have such certificate feel free to add them for additional speed increase. Just know that this might limit the compatibility due to older  devices/software lacking this encryption support.

Server-preferred order

This is a important parameter, since it’s the only way you could keep broad compatibility and high score of the test. It basically gives you the ability to order ciphers by their desirability, and not rely on the client implementation. It’s supported from Java 8, and requires Tomcat 7.0.0.61 or newer.

Setting it up

So now that you have the background, we can set the new SSL Connector in tomcat like this:

<Connector port="443" SSLEnabled="true"
    maxThreads="100" scheme="https" secure="true"
    keystoreFile="/etc/ssl/rsa/keystore.jks"
    keystorePass="changeit"
    URIEncoding="UTF-8"
    compression="on" compressionMinSize="2048"
    compressableMimeType="text/html,text/xml,text/csv,text/css,text/javascript"
    useServerCipherSuitesOrder="true"
    ciphers="
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA
” />
This should give you the green A score and will keep you safe for the foreseeable future, unless some new exploit doesn’t come up.