Addressing SSL Labs cipher warnings to get a better grade

A user messaged me privately saying that he or she was embarrassed to ask publicly about

I wrote the following reply in a private message, which the user later confirmed has solved the problem. I wanted to share this reply publicly so that it can be useful to other people.

These issues are about the cryptographic technology that the web server is willing to use to encrypt communications with clients that connect to it. The TLS protocol is actually extremely flexible (some people have argued much too flexible) in the selection of the underlying cryptographic tools that authenticate and encrypt the connection, yet most software doesn’t show these details to the user.

Usually the term for the settings in question is something like “ciphersuite selection” or “ciphersuite settings”. A good tool to create recommended configurations is

If you used Certbot and had it configure your web server for you, it should try to set defaults based on the recommendations of this Mozilla tool. However, there are lots of ways to use Certbot (or to get Let’s Encrypt certificates) where it doesn’t configure the web server for you, for example when running certbot certonly. In this case, or in certain other cases, you might have other ciphersuite settings somewhere in your web server configuration files.

You might want to look at those configuration flies (probably text files within /etc/apache2 for Apache or /etc/nginx for Nginx) to see if they refer to other ciphersuite settings, which you could most likely replace with the recommendations of the Mozilla configuration generator.

You would probably be looking for an SSLCipherSuite directive for Apache or an ssl_ciphers directive for Nginx. Rather than manually inspecting every configuration file, you could also use grep to do the searching for you, like

grep -r SSLCipherSuite /etc/apache2


grep -r ssl_ciphers /etc/nginx

to see existing configuration files that may have these set somehow.

After updating these settings and restarting your web server, you should receive a better score on the SSL Labs tester.

As for the forward secrecy thing, that should be addressed in the same way. Here’s Ivan Ristić, one of the world’s greatest experts on TLS (and the creator of the SSL Labs testing tool!) earlier today about the forward secrecy issue:

The idea is that if you don’t have ciphersuites that provide forward secrecy, then all of the confidentiality of all of the connections to your server is protected only by one single secret key, which you may keep around indefinitely. If someone later hacked that server or convinced you to turn over that key, they could go back and decrypt all of the previous connections. By contrast, technologies that provide forward secrecy are using an ephemeral key for each connection that is not stored or saved anywhere (and whose secrecy is not protected solely by other longer-lived keys). That means that after the end of each connection, even you as the server operator lose the ability to decrypt the encrypted data that was transmitted during that session (although of course your site might have saved anything from the connection that it found relevant, like in a log file or database, and of course it can continue to access that data). Then nobody can do anything straightforward to let them decrypt all of the old network traffic. This is considered a much stronger security posture to be in.

Further reading:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.