Set Up Let’s Encrypt HTTPS on Ubuntu with Certbot

Let's Encrypt issues TLS certificates, and Certbot handles requesting, installing and renewing them. This guide uses Certbot's snap installation with an existing Nginx or Apache website on Ubuntu.

You will need sudo access and a domain you control. Replace example.com in every command with that domain. The examples request one hostname; add a www name only if it is configured and reachable too.

Make the HTTP site reachable first

Check that the domain's A record points to the correct IPv4 address. If an AAAA record exists, its IPv6 destination must also serve the site correctly. Confirm that the intended virtual host responds over HTTP from outside your network.

The usual web-server flow uses HTTP-01 validation, which requires inbound port 80. Allow HTTPS traffic on port 443 as well, including any cloud firewall or router rules. HTTP-01 does not issue wildcard certificates; wildcard names require DNS-01. These requirements are described in Let’s Encrypt’s challenge documentation.

Install one Certbot distribution

For a new installation on Ubuntu with snapd available:

sudo snap install --classic certbot
/snap/bin/certbot --version

If snapd is missing, install and enable it for your Ubuntu environment first. If you already use an apt-based Certbot installation, follow the migration instructions before switching; do not run two independent Certbot installations. The official snap instructions cover these prerequisites. Calling /snap/bin/certbot explicitly below avoids ambiguity about which binary runs.

Request the certificate for your web server

Back up the existing virtual-host configuration before allowing Certbot to edit it. Choose the commands for the web server that actually serves this domain.

Nginx

sudo nginx -t
sudo /snap/bin/certbot --nginx --redirect -d example.com

Apache

sudo apache2ctl configtest
sudo /snap/bin/certbot --apache --redirect -d example.com

Proceed only if the configuration test passes. Certbot asks for account details and agreement to the terms, validates the hostname and configures the certificate. --redirect requests an HTTP-to-HTTPS redirect, so there is no need to paste a second redirect into the default virtual host.

Both installers and the redirect option are covered in the Certbot user guide. If both web servers run on this machine, use the installer for the frontend handling this domain's public requests.

Check the result

sudo /snap/bin/certbot certificates
curl -I http://example.com
curl -I https://example.com

Check that HTTP redirects to the expected HTTPS hostname and that HTTPS completes without a certificate error. Open the page in a browser too: confirm the certificate covers the hostname and that images, scripts and styles still load. If a CDN terminates TLS, a public request tests the CDN-facing certificate; inspect the origin connection separately.

Verify renewal rather than adding another cron job

sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all | grep -i certbot

The snap includes scheduled renewal. Check that the renewal timer is present and scheduled. A successful dry run tests the renewal path at that moment; it does not prove the scheduler will run in the future. Keeping both checks avoids adding a redundant cron entry to an installation that already renews automatically.

For a failed request or renewal, read /var/log/letsencrypt/letsencrypt.log. Match the error to the hostname, DNS record and validation route involved. A firewall change or stale IPv6 record can break a previously working renewal, so fix that cause before repeating the request. Once the dry run succeeds, retain the log and timer checks as part of the site's maintenance routine.