I’ve been enjoying myself immensely playing around with Let’s Encrypt these last few days, and discovered a couple solution to common problems and issues, so I thought I’d make a small guide mostly for my own reference on how to deploy Let’s Encrypt.
Introduction
For those not in the know, Let’s Encrypt is a free Certificate Authority (henceforth CA) that allows you to provision certificates to your web services programmatically, for free. Let’s Encrypt does quite a few things differently than traditional CAs, the most obvious being that they don’t charge for certificates, and that they only issue short duration certificates, 90 days to be exact. The free part should be obvious, but the reason for the shorter duration isn’t so obvious. Basically, shorter duration means less damage if a key is lost or stolen. Traditionally this would be an impossible task since deploying new certificates every 90 days manually would be just insane. But since Let’s Encrypt requires you to use automated tools to provision certificates, this isn’t an issue at all, so the additional security provided by shorter duration certificates is worth it.
Let’s Encrypt utilises the ACME protocol to automate certificate requests. In a nutshell, the agent (aka. ACME client running on the intended recipient of the certificate) requests a certificate from the CA, and also provisions a challenge response on the server. This challenge response is then checked by the CA, to prove that you are indeed in control of the server you’re requesting a certificate for. The challenge can be done either by placing the challenge in the web root of the server, or by creating a DNS record.
This sounds complicated, but remember that Let’s Encrypt is all about automation, so you don’t really have to do much.
Provisioning a Certificate
So, in reality, nothing of this is really complicated. First, we need a tool to talk to Let’s Encrypt’s CA with. I’m going to use certbot, a tool developed by EEF, since EEF is awesome and their tool is equally awesome. I’m going to go through the motions on a Debian system running NGINX, but the steps are similar for any system that supports certbot.
First, we need to install certbot
$ sudo apt install certbot
We’ll also need to install an adaptor for NGINX so that certbot knows how to talk to our web server. If you’re using Apache or any other webserver, there is similar plugins available for them as well.
$ sudo apt install python-certbot-nginx
Before we let certbot loose, we need to make sure that we have a site enabled with the servername parameter set to the same domain as we are requesting a certificate for. This is most easily checked under /etc/nginx/sites-available/[name of web site]
Then we need to tell certbot what site we’re provisioning a certificate for, and what web server we’re using. The –nginx flag sets the server type, and -d flag is the domain name we are requesting a certificate for.
$ sudo certbot --nginx -d server1.example.com
Certbot will then go to work and present you with a lot of options. First it ask you for an email address for contact purposes.
user@server1:~$ sudo certbot --nginx -d server1.example.com Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator nginx, Installer nginx Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): hostmaster@example.com
Then you need to accept the Terms of Service
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A
After that it gives you the option of joining the EEF emailing list, which you definitely should since as we’ve already stated EEF is awesome!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y
Then certbot works it’s magic and gets you a certificate, and installs it for you in NGINX.
Obtaining a new certificate Performing the following challenges: http-01 challenge for server1.example.com Waiting for verification... Cleaning up challenges Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/server1.example.com
After that, it gives you the option of automatically configuring the web server to redirect to HTTPS from HTTP.
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/server1.example.com
And finally you get to the end, with some links to where you can check that your certificate is installed properly!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://server1.example.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=server1.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/server1.example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/server1.example.com/privkey.pem Your cert will expire on 2019-11-21. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot 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 Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le user@server1:~$
After the installation is done, it’s advisable to run a “dry run” of the renewal process, as certbot renews certificates automatically every 60 days.
$ sudo certbot renew --dry-run
This will give you the following output
Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/server1.example.com.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert not due for renewal, but simulating renewal for dry run Plugins selected: Authenticator nginx, Installer nginx Renewing an existing certificate Performing the following challenges: http-01 challenge for server1.example.com Waiting for verification... Cleaning up challenges - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - new certificate deployed with reload of nginx server; fullchain is /etc/letsencrypt/live/server1.example.com/fullchain.pem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/server1.example.com/fullchain.pem (success) ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Your account credentials have been saved in your Certbot 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 Certbot so making regular backups of this folder is ideal. user@server1:~$
This is the end for Part 1, in the next part we’ll look at how you can add more SANs to your certificates if you later need multiple and tips and tricks!
Categories: Tech
Grumpy Techie 
Leave a Reply