A few days ago, the TLS certificate (SSL is dead, remember?) of my private blog www.hashtagsecurity.com expired without me noticing it, mostly because I paused any activities there to focus on my work here at LastBreach as well as this blog. Since I didn't intend on working on hashtagsecurity.com any time soon, I felt it wasn't necessary to buy a new TLS certficate and set out to replace it with a free one for now. So I signed up for a three month Comodo certificate and long story short, a typo caused me to delete the private key of my newly generated certificate. "A certificate for this domain has already been issued" was the answer I got from the comodo certificate request form, upon trying to issue a new certificate once again.
So I needed another free certificate. Wait, wasn't "Let's Encrypt" supposed to be publicly available at the end of 2015? A quick search brought up, that it's currently in beta trials, which I immediately signed up for. The next day, I got an email saying that the requested domain was whitelisted for beta certificates, along with instruction on how to generate them.
Great, so here are the steps I went through in order to achieve this.
While I am using Apache2 and Let's Encrypt works best with said web server, I didn't want to try it out in my live environment, so I started a new server, setup Apache2 and downloaded the letsencrypt binaries following the instructions in the mail.
$ git clone https://github.com/letsencrypt/letsencrypt $ cd letsencrypt $ ./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory certonly Updating letsencrypt and virtual environment dependencies...... Running with virtualenv: sudo /home/user/.local/share/letsencrypt/bin/letsencrypt ...
Note that the official documentation was of help as well, as, what a surprise, the instructions alone didn't magically give me valid certificates.
There where a couple of errors I ran into, all of which where totally my own fault and easily erradicated once I understood letsencrypt a bit better.
The letsencrypt client will attempt to automatically verify that it's in fact being executed on the server that delivers your website, in my case, www.hashtagsecurity.com. In order to do this, the A-Record must be configured correctly, so that SNI (Server Name Indication) can be used for authentication. Since I didn't ran letsencrypt directly on my production server, I needed to adjust a few firewall rules in order to get everything working.
The biggest problem I ran into was this.
Failed authorization procedure. www.hashtagsecurity.com (dvsni): unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge IMPORTANT NOTES: - If you lose your account credentials, you can recover through e-mails sent to xxxxxxxxxxxxxxxxxxxxxxxxx. - The following 'unauthorized' errors were reported by the server: Domains: www.hashtagsecurity.com Error: The client lacks sufficient authorization To fix these errors, please make sure that your domain name was entered correctly and the DNS A record(s) for that domain contain(s) the right IP address. - Your account credentials have been saved in your Let's Encrypt configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Let's Encrypt so making regular backups of this folder is ideal.
If you see the same error message, just picture the following and begin troubleshooting.
letsencrypt-client => [request for www.hashtagsecurity.com] => letsencrypt-server letsencrypt-server => [answer for letsencrypt-client] => www.hashtagsecurity.com:443
I did the same for port 80, although I'm not sure if it is actually necessary. The rest is fairly easy as the letsencrypt tool guides you through every step.
Success, this is how it should look like.
Since I tested letsencrypt on another server, I had to transfer the certificates to the production host. Using
grep -Ri letsencrypt /etc/apache2/sites-enabled
showed me where the certificates where stored.
Don't copy those, they're just symlinks. The real files are located in
Checking the newly generated certificates shows that they are indeed signed by Let's Encrypt. (Instead of "Happy Hacker CA", for those of you who tried letsencrypt already but don't have a beta access)
After rsyncing the files to the production server, restarting the server and reverting all the iptables changes, www.hashtagsecurity.com was sporting a brand new certificate, which I will have to replace in about three months. Maybe I'll try the fully automated thing on the production server then.