Following on from my post about HSTS, here’s another quick post about HTTPs config for this domain, running on NGINX. This time, removing old SSL ciphers which are known to be insecure.

TL;DR - Update your /etc/letencrypt/options-ssl-nginx.conf and /etc/nginx/sites-available/blah files to prune off a bunch of those fallback options in the ssl_ciphers list.

For my config it meant I threw away all the ones that start with DHE or EDH

Then reload the config with something like sudo service nginx reload.

A friend recently asked me if I’d run this site through the Qualys SSL Tests after I got the LetsEncrypt (LE) stuff working. I hadn’t, so I duely threw the URL in the box and hit the button.

The result was pretty good, almost all greens and “OK” results - well done NGINX and LE teams! (I take no credit myself, I just followed their guides). But the overall score was only a ‘B’ and Qualys painted it yellow, saying it was limited to a B because the site allowed some weak cipher fallbacks.

Well, can’t blame LE for that, they even say their config is designed to work with as many browsers as they can, including some of those fossilised, virus-ridden throwbacks of the Windows XP era (or even the archaeological Win95 age).

Improving on ‘OK’

However, I don’t need to support those rotting zombie browsers, ‘cos it’s my site and I can make the rules however I like. So, modern cipher suites only, and hopefully a nice green test page as a result.

Editing /etc/nginx/sites-available/appendixv was the first step. Find the ssl_ciphers, see a huge pile of stuff I can’t read, and panic slightly. Ok, someone else is bound to have done this before … yup “Strong SSL Security on nginx” thanks to Remy van Elst (their post has a load of other good NGINX stuff too).

So ssl_ciphers is just a space separated list of codes, from most to least preferred, and the Qualys result said the last 5 of my ciphers were weak. Well, how about I just hack the last 5 entries off the list - the names kind of match up.

Now, LE’s certbot renews my certs regularly and updates the relevant SSL lines in my nginx config. So at next renewal it’ll overwrite the changes in “appendixv”. Which means I need to edit the LE config to correct the same ssl_ciphers line.

root$ nano /etc/nginx/sites-available/appendixv
(hack 5 entries)
root$ nano /etc/letsencrypt/options-ssl-nginx.conf
(hack same 5 entries)
root$ service reload nginx

Then it’s time to clear cache and re-run the Qualys test …

Whoop, I get an ‘A’!

It looks like getting an ‘A+’ would require me to disable TLS 1.0 stuff entirely. But that throws out quite a lot of tools and browsers, some of which I do still occasionally use on old devices, so I’ll let those middle-aged citizens visit for a while longer.


One final thing - there’s a note about “DNS CAA”. Now I don’t really care about this for appendixv, ‘cos it’s mainly a vanity domain, but hey it’s bonus points I can get if my domain registrar supports these records … aaaaand they do (although their help pages don’t know about that).

A quick browse of the LE pages about CAA (starting from here), and it looks like the config I want is…

  • host = “” (or * as my registrar calls it)
  • flag = 0 (according to RFC 6844)
  • tag = issuewild (or maybe issue - RFC seems waffly on this point)
  • value = “” (according to the LE pages)

Another CAA article from dnssimple suggests adding an iodef CAA record too, with the value being a “mailto:a@b.c” entry to inform if there are any invalid CA attempts. That sounds handy, so I’ll add one of those records too.

Well, the DNS editor my registrar uses finally agreed to those values after some persuading. Time to wait a while for DNS propagation then once dig suggests DNS has done its thing I’ll redo the Qualys test and see if I get an extra bit of green text.

CAA update finally worked

whyyy are we waaaiting? Come on DNS, sigh. huh? Me? impatient? dunno what you mean.

After a brief chat to tech support at my domain registrar, it turns out their GUI DNS editor uses slightly different syntax to what the help pages for it say. But the GUI doesn’t actually tell you that anything is wrong, just shows a nice green.

Anyway, a helpful guy called Ed sorted out the syntax and poked the publishing daemon.

And the results are, well, the same ‘A’ rating as before, but with a bit more green text.

But I do now have CAA records, as can be seen with a quick dig at the domain…

$ dig type257

; <<>> DiG 9.10.3-P4-Debian <<>> type257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14718
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;			IN	CAA

;; ANSWER SECTION:		600	IN	CAA	0 issuewild ""		600	IN	CAA	0 iodef "mailto:me@myemail"

Hurrah for tiny improvements to things that don’t matter very much!