Getting started with Let’s Encrypt & Certbot – LE Series Part 1

le-logo-twitter

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!

Advertisements


Categories: Tech

Tags: , , , , , , , , , , , , ,

1 reply

Trackbacks

  1. Enabling HTTP/2 on NGINX – NGINX Tricks Part 3 – Grumpy Techie

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: