Use Certbot to Enable HTTPS with NGINX on Debian

Select distribution:
Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.

This guide provides instructions on using the open source Certbot utility with the NGINX web server on Debian 10 and 9. Certbot dramatically reduces the effort (and cost) of securing your websites with HTTPS. It works directly with the free Let’s Encrypt certificate authority to request (or renew) a certificate, prove ownership of the domain, and install the certificate on NGINX (or other web servers).

Supported distributions: Debian 10 (Buster) and Debian 9 (Stretch). Debian 8 (Jessie) is no longer supported by Certbot.

Before You Begin

Before continuing with this guide, you need a website accessible over HTTP using your desired domain name. Breaking this down further, the following components are required:

  1. A server running on Debian 10 or 9 with credentials to a standard user account (belonging to the sudo group) and the ability to access the server throughSSH or Lish. Creating a Compute Instance and Setting Up and Securing a Compute Instance guides for information on deploying and configuring a Linode Compute Instance.

  2. A registered domain name with DNS records pointing to the IPv4 (and optionally IPv6) address of your server. A domain can be obtained through any registrar and can utilize any DNS service, such as Linode’s DNS Manager. Review the DNS Records: An Introduction guide for more information on configuring DNS.

  3. The NGINX web server software installed on your server and configured for your domain. You can review the How to Install NGINX on Debian 10 guide for information on installing and configuring NGINX.

Note
This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you are not familiar with the sudo command, see the Users and Groups guide.

Understanding HTTPS, TLS, Let’s Encrypt, and Certbot

HTTPS and TLS/SSL

HTTPS builds upon the original Hypertext Transfer Protocol (HTTP) standard to offer a more secure browsing experience. It encrypts network traffic using the Transport Layer Security (TLS) protocol, which replaces the older (and now deprecated) Secure Sockets Layer (SSL) technology. HTTPS protects the privacy and integrity of any data in transit and authenticates a website for the end-user. For this reason, HTTPS must be implemented on websites that handle financial or personal data. However, all domains are strongly encouraged to enable HTTPS and a majority of all sites now use it. Review the Understanding TLS Certificates and Connections to learn more about TLS.

Let’s Encrypt

A web server must possess a signed public-key certificate from a trusted Certificate Authority before it can accept HTTPS requests. Let’s Encrypt is one of the most widely-used of these authorities. It manages a free automated service that distributes basic SSL/TLS certificates to eligible websites. Let’s Encrypt leverages the Automatic Certificate Management Environment (ACME) protocol to automate the certificate granting process through a challenge-response technique. The Let’s Encrypt site provides more comprehensive technical details about domain validation.

Certbot

Certbot was developed by the Electronic Frontier Foundation (EFF) with the end goal of improving web security by enabling HTTPS. It is compatible with most operating systems as well as the most popular web server software, such as Apache and NGINX. Certbot is responsible for communicating with Let’s Encrypt to request the certificate, perform any required ACME challenges, install the certificate, and configure the web server. It can also automatically handle the certificate renewal process. See the About Certbot page on Certbot’s website for additional information

Configuring Firewall Rules with UFW

Any firewall configured on your server needs to allow connections over HTTPS (in addition to HTTP and any other services/ports you require). This section covers enabling and configuring UFW (UncomplicatedFirewall). UFW is the default firewall management tool on Ubuntu and is also available on Debian and Fedora. It operates as a easy to use front-end for iptables.

You can skip this section if you are using a different firewall (such as Linode’s Cloud Firewall service), have already configured your firewall rules, or do not wish to use any firewall.

  1. If UFW is not installed, install it now using apt or apt-get.

    sudo apt update
    sudo apt install ufw
    
  2. Add firewall rules to allow ssh (port 22) connections as well as http (port 80) and https (port 443) traffic.

    sudo ufw allow ssh
    sudo ufw allow http
    sudo ufw allow https
    

    Your server may require additional rules depending on which applications you’re running (such as mail servers or database servers) and if those applications need to be accessible from other systems.

  3. Enable UFW if its not already enabled.

    sudo ufw enable
    
  4. Verify that UFW is enabled and properly configured for ssh and web traffic.

    sudo ufw status
    

    This should return a status of active and output the firewall rules that you just added.

For more advanced configuration, review the How to Configure a Firewall with UFW guide.

Installing Snapd

Snap is a package manager developed by Canonical (creators of Ubuntu). Software is packaged as a snap (self-contained application and dependencies) and the snapd tool is used to manage these packages. Since certbot is packaged as a snap, we’ll need to install snapd before installing certbot. While it’s installed by default on Ubuntu 16.04 and later, its also available for most other Linux distributions.

  1. If snapd is not installed, install it now.

    sudo apt update
    sudo apt install snapd
    
  2. Install the core snap.

    sudo snap install core
    sudo snap refresh core
    

Installing Certbot

The next step is to install Certbot using the snap command.

  1. Remove any previously installed certbot packages to avoid conflicts with the new Snap package.

    sudo apt remove certbot
    
  2. Use Snap to install Certbot.

    sudo snap install --classic certbot
    
  3. Configure a symbolic link to the Certbot directory using the ln command.

    sudo ln -s /snap/bin/certbot /usr/bin/certbot
    

Requesting a TLS/SSL Certificate Using Certbot

During the certificate granting process, Certbot asks a series of questions about the domain so it can properly request the certificate. You must agree to the terms of service and provide a valid administrative email address. Depending upon the server configuration, the messages displayed by Certbot might differ somewhat from what is shown here.

  1. Run Certbot to start the certificate request. When Certbot runs, it requests and installs certificate file along with a private key file. When used with the NGINX plugin (--nginx), Certbot also automatically edits the configuration files for NGINX, which dramatically simplifies configuring HTTPS for your web server. If you prefer to manually adjust the configuration files, you can run Certbot using the certonly command.

    • Request a certfifcate and automatically configure it on NGINX (recommended):

       sudo certbot --nginx
      
    • Request a certificate without configuring NGINX:

       sudo certbot certonly --nginx
      

      To request the certificate without relying on your NGINX installation, you can instead use the standalone plugin (--standalone).

    During the installation process, Certbot will prompt you for some basic information including your email address and domain name.

  2. Enter email address. The first prompt is to request an email address where Certbot can send urgent notices about the domain or registration. This should be the address of the web server administrator.

  3. Accept terms of service. Certbot next asks you to agree to the Let’s Encrypt terms of service. Use the link in the output to download the PDF file and review the document. If you agree with the terms, enter Y. Entering N terminates the certificate request.

  4. Optionally subscribe to mailing list. Certbot asks if you want to subscribe to the EFF mailing list. You can answer either Y or N without affecting the rest of the installation.

  5. Enter domain name(s). Certbot now requests a domain name for the certificate. If there is a virtual host file for the domain, Certbot displays the names of the eligible domains. Select the numbers corresponding to the domains you are requesting certificates for, separated by spaces. If the domain doesn’t appear, you can enter the name for each domain without the http or https prefix. For each domain name, you should request separate certificates with and without the www prefix. If you have more than one domain to certify, separate the names with either a space or a comma.

    www.example.com example.com
    
    Note
    Certbot displays the names of domains configured in the server blocks configured withing NGINX. Select the numbers corresponding to the domains you are requesting certificates for, separated by spaces.
  6. Certbot then communicates with Let’s Encrypt to request the certificate(s) and perform any necessary challenges as defined in the ACME standard (see Challenge Types). In most cases, ownership can be proven through the HTTP challenge, which automatically adds a file on your web server. If you wish to change the challenge type or perform challenge manually, see the Manual section in the Certbot documentation.

If the operation is successful, Certbot confirms the certificates are enabled. It also displays some information about the directories where the certificates and key chains are stored, along with the expiration date. Certificates typically expire in 90 days.

Requesting a certificate for www.example.com
Performing the following challenges:
http-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
...
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.example.com/privkey.pem
our certificate will expire on 2021-05-29.

Testing the HTTPS Connection

The next step is to confirm the website is properly configured to use your new certificate and is accessible over HTTPS. To do this, navigate to your website on a web browser, making sure to specify the https:// protocol when entering your URL. If a lock is visible to the left of the domain name on the browser’s address bar, the certificate is likely working as expected. If the certificate is not installed properly, the browser displays a warning page.

You can also enter your domain into the SSL Server Test by Qualys SSL Labs to verify that the TLS/SSL certificate has been properly installed and configured.

Renewing a TLS/SSL Certificate Using Certbot

Upon installation, Certbot is configured to renew any certificates automatically. It is not necessary to manually request an updated certificate or run Certbot again unless the site configuration changes. However, Certbot makes it possible to test the auto-renew mechanism or to forcibly update all certificates.

Test Automated Renewals

To confirm Certbot is configured to renew its certificates automatically, use certbot renew along with the dry-run flag.

sudo certbot renew --dry-run

Certbot inspects the certificates and confirms they are not due to be renewed, but simulates the process anyway. It displays details regarding whether the renewal would have been successful.

Cert not due for renewal, but simulating renewal for dry run
...
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)
  /etc/letsencrypt/live/www.example.com/fullchain.pem (success)

Manually Renew Certificate

To manually force Certbot to renew all certificates, use the renew command without any options.

sudo certbot renew
Note
Certbot does not renew certificates unless they are scheduled to expire soon. However, adding the --force-renewal flag to the renew command forces all certificates to be renewed regardless of their status. However, there is usually no good reason to force renewals. Do not use the force-renewal option too frequently as this could exceed the Let’s Encrypt rate limit for a domain certificate.

Deleting a TLS/SSL Certificate Using Certbot

The certbot revoke command revokes a certificate and provides an option for deleting it. The --cert-path parameter must include the location of the certificate. Certbot indicated the certificate directory when it granted the certificate.

sudo certbot revoke --cert-path /etc/letsencrypt/live/www.example.com/fullchain.pem
Important
This option should not be used if you plan to host this domain on the same Linode again. Certbot might not always clean up the configuration files properly, and there could be errors if you request the same certificate again later.

Learning More About Certbot

Although Certbot is relatively easy and straightforward to use, EFF has plenty of documentation available for more advanced scenarios. There is a FAQ which covers many common problems. The Certbot site also contains an extensive documentation section. Support requests are best handled through the Let’s Encrypt community page.

This page was originally published on


Your Feedback Is Important

Let us know if this guide was helpful to you.


Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.