Provision an SSL certificate using Certbot by Let's Encrypt

Legend

Parts of this exercise are annotated with the following icons:

• A task you MUST perform to complete the exercise
• An optional step that you may perform to make sure that everything is working correctly, or to set up additional tools that are not required but can help you
• The end of the exercise
• The architecture of the software you ran or deployed during this exercise.
• Troubleshooting tips: how to fix common problems you might encounter

Install Certbot

Install Certbot with the following command:

$> sudo apt install certbot python3-certbot-nginx

Obtain a TLS certificate from Let’s Encrypt

Follow the instructions for nginx and Linux (snap) starting at step 6:

Tip

When the instructions ask you to “Choose how you’d like to run Certbot”, you can choose the simplest option which is to “get a certificate and have Certbot edit your Nginx configuration automatically to serve it”.

Once you are done, your web site or application should be accessible over HTTPS.

You should take a look at your nginx site configuration file(s) in the /etc/nginx/sites-available directory, to see the changes Certbot has made.

What have I done?

You have run Certbot to request a TLS certificate from the Let’s Encrypt certificate authority (CA).

Before issuing a certificate, Let’s Encrypt (or any other certificate authority) requires domain validation, i.e. you must provide some proof that you control the server reachable at the certificate’s domain name. Since you have run Certbot on your server, it has automatically provided that proof by asking Let’s Encrypt to perform an HTTP challenge, and then completing the challenge by providing the appropriate file through nginx.

Certbot saved the certificate it obtained from Let’s Encrypt somewhere into the /etc/letsencrypt directory. It then modified your nginx site’s configuration file to use that certificate.

More information

Certbot has been able to automatically do all these things for you because you have run it with administrative privileges by prefixing it with sudo.

Because the modified nginx configuration for your site now listens on port 443 for HTTPS and provides a valid TLS certificate, your todolist is now accessible with an https:// instead of an http:// URL, and the TLS protocol is used to encrypt communications between your browser and the server.

Architecture

This is a simplified architecture of the main running processes and communication flow at the end of this exercise:

Troubleshooting

Here’s a few tips about some problems you may encounter during this exercise.

No names were found in your configuration files

If Certbot tells you that “No names were found in your configuration files” but you have nginx sites that are configured, this may be because you have an underscore character (_) in your subdomains, e.g. jde.archidep.ch.

Although many tools support it, underscore are technically not allowed in domain names. You will have to change your subdomain for Certbot to recognize it as valid.

There are two things you need to do:

• Log back into Gandi.net and add a new A record for your Azure VM just like you did during the Domain name configuration exercise.

  Use something short like jde and *.jde (as long as it does not conflict with anyone else’s subdomain), with the same IP address as before (the public IP address of your Azure VM).

• Replace your old subdomain by the new one in all your nginx configuration files, for example:

  $> sudo nano /etc/nginx/sites-available/clock
  $> sudo nano /etc/nginx/sites-available/revprod
  $> sudo nano /etc/nginx/sites-available/todolist
  

  Then test and reload the nginx configuration with:

  $> sudo nginx -t
  $> sudo nginx -s reload
  

Make sure your sites work at their new address. If they do, the certbot command should now also detect them.

Tip

It may take a few minutes for the new DNS entries to propagate. If you are sure the new DNS entries are correct but it doesn’t work, try again a little while later.