Skip to content

Latest commit

 

History

History
165 lines (123 loc) · 6.78 KB

certbot-deployment.md

File metadata and controls

165 lines (123 loc) · 6.78 KB
Raw

Provision an SSL certificate using Certbot by Let's Encrypt

The goal of this exercice is to provision a Let's Encrypt SSL certificate for an application deployed in previous exercices using Certbot.

Legend

Parts of this guide 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.
  • ⚠️ Critically important information about the exercise.
  • 💎 Tips on the exercise, reminders about previous exercises, or explanations about how this exercise differs from the previous one.
  • 👾 More advanced tips on how to save some time. Challenges.
  • 📚 Additional information about the exercise or the commands and tools used.
  • 🏁 The end of the exercise.
    • 🏛️ The architecture of what you deployed during the exercise.
  • 💥 Troubleshooting tips: how to fix common problems you might encounter.

💎 Requirements

This exercise assumes that you have deployed at least one web site or application during previous exercices, and that you have configured nginx to serve it.

❗ 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:

💎 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.

📚 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:

Architecture

Architecture PDF version.

The only thing that has changed compared to the previous exercise is that you are now accessing your application over an encrypted HTTPS/TLS connection instead of insecure HTTP.

💥 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 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. john_doe.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 Configure a domain name exercise.

    This time, use john-doe instead of john_doe and *.john-doe instead of *.john_doe (or something shorter 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.

💎 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.