Let’s Encrypt is a very convenient way to enable https for your website. This short primer will help you getting all steps done in just a few minutes. I assume you to have set up a fresh web server that is already able to receive http traffic; you should be able to log in on your server using ssh. I’m restricting myself to nginx only.

Install CertBot

Cerbot is only one of many possible client tools retrieving Let’s Encrypt certificates. But it’s the only one that’s recommended by Let’s Encrypt, so let’s stick to it. On certbot’s homepage, select the type of web server and operating system of your server that you are using. You will be redirected to a page telling you how to install certbot; just follow this first step. Depending on your system or distribution, you might receive a ‘certbot’, ‘certbot-auto’, or ‘letsencrypt’ tool: they’re equivalent. This article refers to ‘certbot’, so change it to the name of whatever you have installed on your system.

Manual and automatic modes; certbot’s parameters

Certbot offers a lot of parameters, which can be a bit confusing for first-time users. You may either run it in manual mode which is preferred by many as it gives you more control about the install process and your webserver doesn’t have to be stopped when receiving the certificate(s) – or you run certbot in automatic mode which skips a few steps. Whichever you want to use we will be calling certbot’s certonly command. Add at least one -d section, followed by your domain. If you want a certificate for a specific website only, append a -d parameter with the website’s name, e.g. -d www.mydomain.org. Omit the “www.” if you want a catchall certificate for all subdomains of mydomain.org. Now we have to deal with the authenticator, or plugin. There are four of them to choose from, webroot and manual the most common ones. You either select them with a –<plugin> syntax (e.g. –webroot) or with the -a parameter (e.g. -a manual). -a(or the appropriate “–” version) is the authenticator parameter that eventually initiates the whole process, from validating that it’s you who controls the affected domain(s), retrieving the certificates, and finally installing them in /etc/letsencrypt. If you choose manual mode, you will have to place a challenge file in a certain place by yourself; if you select –webroot, than certbot will do this for you. We’re going to cover both variants here, but before executing certbot (or certbot-auto), let’s do the nextpreparatory step.

Prepare your webserver

The webroot plugin creates a temporary file for each domain in your webserver’s directory /.well-known/acme-challenge. Your webserver must be enabled to server from hidden directories like .well-known, so let’s tell it this explicitlyby including a location /.well-known/acme-challenge on your server’s definition that serves these challenge files.

When retrieving the certificates, certbot does a request on this address: http://site.yourdomain.tld/.well-known/acme-challenge/<a-long-token-string>. The content type for this challenge file has to be ‘text/plain’. Save this configuration as /etc/nginx/letsencrypt-acme-challenge.conf.

By the way, this whole procedure (and the name ‘ACME’) wasn’t invented by Let’s Encrypt but by the IETF Network Working Group. Read all about it here, especially sections 7 and 8.

Your webserver’s sites-enabled/default file should look like this (note the include line):

Obtaining the certificate

Above we were discussing manual and webroot mode: depending on which method you prefer, you have different things to do in order to retrieve the certificates.

webroot mode

certbotcertonly --webroot -w [website's root dir]-d [subdomain].yourdomain.tld [-d [subdomain].yourdomain.tld]

If you are using webroot mode, you must add -w followed by the site root’s directory, e.g. /usr/share/nginx/www. certbot displays its client, does the validation, gets the certifcates and saves them into/etc/letsencrypt/live/site.yourdomain.tld/.

manual mode

certbotcertonly -a manual -d [subdomain].yourdomain.tld [-d [subdomain].yourdomain.tld]

At a certain point of installation, certbot requires you to set up the challenge file. The appropriate message looks like:

Make sure your web server displays the following content at
http://site.yourdomain.tld/.well-known/acme-challenge/<a-rather-long-string>before continuing:<even-longer-string>


Login on your server, change to the .well-known/acme-challenge, and do a:
echo -n "<even-longer-string>" > <a-rather-long-string>
thus creating the challenging file with the needed security token. Remember: this is for proving your authority of this site to certbot. After providing this information, your certificates will be saved into/etc/letsencrypt/live/site.yourdomain.tld/.

Using the certificates

Now what? In/etc/letsencrypt/live/site.yourdomain.tld/ you now have four files: cert.pem, chain.pem, fullchain.pem, and privkey.pem. The last one is your private key: don’t ever publish this to anyone! cert.pem is the ‘pure’ certificate by itself, chain.pem contains the additional intermediate certificate or certificates that web browsers will need in order to validate the server certificate. fullchain.pem contains all certificates, including the server certificate (aka leaf certificate or end-entity certificate). According to the Let’s Encrypt documentation, this is what Apache >= 2.4.8 needs for SSLCertificateFile, and what Nginx needs for ssl_certificate. In order to use them, create a file /etc/nginx/ssl.conf with following content:

In some articles you will see cert.pem instead of fullchain.pem; I wouldn’t recommend this. Because when you do a check of your SSL configuration with SSL Labs, you probably will get a ‘B’ grade only, complaining about a “SSL Chain Incomplete” issue. Even Let’s Encrypt’s recommendation to use both cert.pem and chain.pem in SSL.config wouldn’t correct this. Perhaps it’s the extra download needed for a client in order to obtain the whole certificate chain; anyway, it’s safe to use fullchain.pem, instead.

What’s still missing is the complete nginx configuration of your web site. Look at this one:

Note the rewrite in the server’s http configuration: this makes sure that every request on port 80 gets redirected to port 443 (https). The included ssl.conf is the one we discussed above. Don’t forget a ‘nginx reload’ after editing nginx’s config files. That’s it.

Further reading: Certbot documentation at readthedocs.io (which is a bit easier to read than the docs atcertbot.eff.org.