Let’s Encrypt Wildcard Certs

Recently Let’s Encrypt announced that they would be supporting wildcard certs. I was pretty excited to hear about this as many times I would like to get certs for machines that might not be accessible on the internet. Currently I didn’t see an easy way to do this. With the new certs you could get a cert on your web server for your domain and use that cert on all the other machines in your domain that need TLS as well.

I decided to try it out and see how easy it was to do. I updated my certbot client to version 0.22 and did some google around and found out that you have to specify the new acme version 2 servers on the client command line in order to generate the wildcard cert. So I found the command and fired it up:

./certbot-auto --server https://acme-v02.api.letsencrypt.org/directory -d *.haskovec.com --manual --preferred-challenges dns-01 certonly

The command runs and asks you a few questions and then presents a DNS challenge. They give you a TXT record that you need to update in your DNS server to prove that you control the domain. I added the record and waited a couple of minutes and next thing you know it generated my new cert.

I updated my NGINX config to point to the new cert restarted the server and hit my site. Next thing I see is an SSL error. It turns out if you only have *.haskovec.com in the cert that isn’t a valid server for the base domain of haskovec.com. So I reran the command again and specified the following:

 ./certbot-auto --server https://acme-v02.api.letsencrypt.org/directory -d haskovec.com -d *.haskovec.com --manual --preferred-challenges dns-01 certonly

This time it asked me if I want to expand my cert to include the new domain name. I said yes. Next it had 2 challenges that I needed to insert into my DNS TXT record. I added them both and finished generating the new cert. When I restarted NGINX my site was back. I ran the https://www.ssllabs.com/ security test on my site and I am still at an A+.

All in all a very easy process and I recommend people give it a try.

SSL Certificates and Google Domains

Recently I ported my domain hosting from Godaddy to Google Domains. My main reason for doing so was to save money. Domain names on Godaddy cost $3 more per year, plus they charge you for privacy on whois searches whereas Google includes that for free. It was a fairly easy process to transfer my domain names in, but configuring the DNS was a little bit weird as their zone file editing interface was different that godaddy’s. However I thought I had it all good and working so I was happy with my setup.

Then last night one of my friends mentioned that he had just renewed his SSL certificate. That got me thinking I only had about 2 weeks left on my certificate and I needed to do that as well. I had mentioned previously that I switched my SSL certificates to Let’s Encrypt. The great thing about Let’s Encrypt is that it is free, and once you get it setup, less hassle to renew that other free certificate sites that I had used in the past. The drawback seems to be that they only issue certificates that are good for 90 days. I updated my Let’s Encrypt software (it is based out of a Github repository so there is normally a new version when you need to renew.) When I ran the renew command it failed on www.haskovec.com. That is when I realized that I had misconfigured my cname record on Google Domains DNS setting and www. was completely broken only haskovec.com worked. It took me a little while to figure out. On Godaddy I think I would do the cname of www and point it to @ or * I don’t recall which they used. Google doesn’t let you point the cname to @. Aftering some googling I found out that on their DNS setup you have to point to your hostname that is registered at @. So it ends up being cname www and it points to haskovec.com. Once I got that taken care of my certificate renewed without any issue.

While I was in there messing around I decided I would disable TLS 1.0. Doing so means dropping support for a ton of browsers including IE10. But it is widely considered as the next protocol to be hacked and at this point pretty much everyone supports 1.2 and the handful of readers I have I expect to be running current browsers (whether on their phones or computers.) I reran the Qualys SSL Test to make sure that I hadn’t broken anything. All looked well with the higher score now on the protocol section and many more test browsers that failed. In the course of running that test I noticed the HSTS preloading test that they are doing now. I didn’t even realize such a thing existed. I did some research and added the preload header to my HSTS header on my server and put my site on the preload list for Chrome. We shall see if that works or if I meet all the requirements, but I think I do. While I was editing my headers I noticed that I was doing the domain name rewriting wrong if the person came in through https://www.haskovec.com/ The code was working if they either came in without the www or they came in on www without the https. So it ended up being a useful night as I found 2 issues in my server config I was able to fix. In the course of writing this post I realized I should add the other cnames I have registered for this domain to my SSL certificate so that will be the next thing on my agenda.

The downside of updating your server config

So a little while back when I had been playing with Pagespeed I somehow managed to break certificate stapling on my server. So when I ran the Qualys SSL Server Test my score had fallen to a B! I messed around and tried a few things and I had no luck getting it to work. One of my friends said the site started to give weird errors under Chrome on Android. Then I was reading this CertSimple Blog entry yesterday and they mentioned the Mozilla Server Side TLS Project, which I don’t think I had heard of. Basically what it does is you enter your server version and your OpenSSL version and how aggressive you want your security settings and it will generate a sample config for you. It will tell you based on how aggressive your settings are what the minimum browser versions are. For example of of the differences between Intermediate and Modern is that they drop support for TLSv1 in Modern and only support TLSv1.1 and TLSv1.2. For most browsers this doesn’t seem to be an issue but if you are running IE that means the minimum browser version is IE 11. I debated whether I should drop TLSv1 support or not, but I figure if I keep it I can support IE back to 7, though I can’t imagine any software engineers that might check out this blog using IE anyway. For now I have kept it but one of these days I will drop it because given the rate of SSL issues with Freak and Logjam lately, it is only a matter of time before someone finds a hole in TLSv1.

As for my issue Mozilla in their example config said my ssl_certificate setting should point to my signed key plus intermediates, whereas previously I only had my signed key there. I had intermediates in the ssl_trusted_certificate with the root certificate, and that was working prior to my gzip changes but for some reason now it wants them in both places or else it does a separate download on the intermediate certificate and drops me to a B. So I am back to my coveted A+ rank, and I think the lesson I learned is one a coworker mentioned to me. They said that they put all of their config files in git so that any time they make a change if there are issues they can look at all previous revisions. In the future if I make any changes here on my server config I think I may do the same and setup a config file repository before I touch anything again just to have easy version control and knowing how to revert if things get ugly.

Security is about tradeoffs

When I was working on this site on of the first things I did after setting up SSL was to run the Qualys SSL Labs Test on my site. This tool will analyze your site security and point out any weaknesses and assign a grade to your site. I initially scored a C and used the test results to get this site up to an A. When I got to an A I thought I was doing well as I had robust forward secrecy and my scores 100, 95, 80, 90. Then I saw this blog post over here and noticed his site while also had an A score he had a key exchange score of 100. This sent me down the rabbit hole of tweaking SSL configs to figure out how to really get a high score on this test.

After hours of testing I determined the difference was disabling the kEDH Ciphers which are “cipher suites using ephemeral DH key agreement, including anonymous cipher suites.” Once those are disabled my key exchange score went up to 100, however I lost my robust forward secrecy rating. There is the tradeoff if you drop those ciphers there are a bunch of devices out there that can’t do forward secrecy anymore, but if you keep them you are using what are considered to be weaker ciphers. In the end I decided to drop them, and then since I was in there I continued tweaking to one up Christopher Burg and got my site all the way up to an A+ before his. Who says a little friendly competition isn’t good motivation.

For anyone who is curious I looked into what it would take to get all 100s on the test and it is a price I am unwilling to pay at this time. Basically you have to run only TLS1.2 and have things really locked down. The other thing I would like to figure out is are the Camellia ciphers good and considered secure? I saw some sites recommending them, but I haven’t really heard much about them. I would love to know what the security community thinks of them, whether they are considered secure or efficient. I considered testing with them, against the Qualys SSL report card but it was midnight when I finally got to my A+ so I just left things where they were. If you want to check out my score on the test go here. Also check out this lovely image of my report card:

ssl-reportcard