Using Let’s Encrypt SSL certificates
Recently, I needed to use “Let’s Encrypt” to issue a few SSL certificates. “Let’s encrypt” looked really cool as it offers organisations/individuals a way to quickly and cheaply get SSL certificates. I ran into a few issues along the way, though. This post is intended to help people avoid those same issues I ran into.
Issuing certificate
This might sound like a simple topic but it took me a while before I got all the pieces together. “Let’s Encrypt” is a really cool technology but it’s still in its early days so things usually don’t go as smooth as we would like.
If you follow the official documentation you will be instructed to use `letsencrypt-auto` client. I found that `letsencrypt.sh` is a lot better tool. Following is a short list of pros of using `letsencrypt.sh` over official client:
- supports DNS challenge
- hooks, especially it’s AWS Route 53
- is better documented (shorter and more concise).
When issuing certificates, DNS challenge protocol is a lot better option than HTTP one, as it allows you to issue a certificate without having to run a special server or reconfigure your existing one. The caveat is that you need to be able to programmatically set TXT records in your DNS server (hint: Route 53 :) )
On that note, route 53 hook is really useful but the one mentioned in the documentation as an example has some issues. In particular it doesn’t deal very well with subdomains. For me, and I assume most people, this is a deal breaker. Most of projects that I work with run on some subdomain.
A “fixed” version of Route 53 hook can be found in this github repo — https://github.com/markovuksanovic/letsencrypt.sh-hooks. This script will be able to handle subdomains. To successfully generate a certificate you will need AWS secret key and access key id. My advice is to create a user with very limited permissions and then set those two environment on the machine where you will be running `letsencrypt.sh`. After you’ve set everything up, execute the following command to finally generate your certificates:
./letsencrypt.sh -cron -domain subdomain.example.com \
-hook ./hooks/route-53.rb -challenge dns-01If everything went well you will end up with you’re new certificates in `certs/subdomain.example.com/` folder.
Congratulations. Now onto our next step.
Verifying certificates
After generating the certificates, you need to verify that everything actually adds up and makes sense. You should do this before deploying certificates onto a server. This step might save you a lot of time (in terms of debugging) in case anything went wrong.
As mentioned previously, your certificates should be in your `certs` folder. Using my subdomain.example.com domain, you should find `private.pem` and `fullchain.pem` files in `certs/subdomain/example.com`.
Public and private keys contains some parameters used for encryption. One of those parameters is `modulus`. This parameter has to be the same in both public and private key. We can use it to verify our keys. To do that execute the following two commands and make sure you get exactly same output.
1. openssl x509 -in certs/subdomain.example.com/fullchain.pem -noout -modulus | openssl md52. openssl rsa -in certs/subdomain.example.com/privkey.pem -noout -modulus | openssl md5
And that’s it! Now, we can finally use our certificates.
