Certbot and Let's Encrypt: Automate HTTPS Certificates on Your Server

Let's Encrypt is a free, automated certificate authority, and Certbot is its most popular client. Together they let you serve your site over HTTPS without paying for or manually renewing certificates. Let's Encrypt certificates are valid for 90 days, which sounds short but is deliberate: it encourages automation, and once renewal is automatic you never think about it. This guide shows how to set it up and, more importantly, how to verify that renewal keeps working.

What you need first

• A domain name whose A record (and AAAA record, if you use IPv6) points to your server's IP address.
• A web server already answering on port 80 for that domain.
• Ports 80 and 443 open in your firewall. Port 80 is required for the standard HTTP-01 validation, where Let's Encrypt fetches a small file from your site to prove you control the domain.

If the DNS record is wrong or has not propagated, validation fails. Check with dig +short example.com before you start.

Install Certbot

The Certbot project recommends installing through snap on most distributions, and its website at certbot.eff.org gives an up-to-date instruction page for your web server and operating system. Distribution packages also exist and are a fine choice on Debian and Ubuntu if you prefer apt:

sudo apt install certbot python3-certbot-nginx

Use python3-certbot-apache for Apache. Whichever route you choose, do not mix two installations of Certbot on the same machine, because their renewal jobs can conflict.

Get a certificate

The plugin approach edits your web server configuration for you:

sudo certbot --nginx -d example.com -d www.example.com

Certbot asks for an email address (used for expiry warnings), validates both names, installs the certificate and offers to add an HTTP-to-HTTPS redirect. List every hostname you want covered with -d. The certificate and key are stored under /etc/letsencrypt/live/example.com/ as fullchain.pem and privkey.pem. Keep the private key private, and refer to the live symlinks in your configuration, never the files in archive, because renewal updates the links.

Other validation methods

• Webroot: sudo certbot certonly --webroot -w /var/www/example.com/public -d example.com places the validation file in your site folder and leaves your server configuration untouched. Good when you manage the web server config yourself.
• Standalone: certbot certonly --standalone runs a temporary web server on port 80. Your own web server must be stopped for that moment, so it suits non-web services.
• DNS validation: required for wildcard certificates such as *.example.com. It proves control by creating a DNS TXT record, and automating it needs a Certbot DNS plugin for your DNS provider.

Check that renewal is automatic

Package and snap installs add a scheduled job, normally a systemd timer, that runs certbot renew regularly. Certbot only renews certificates that are close to expiry, so frequent runs are harmless. Confirm the timer exists and rehearse the process:

systemctl list-timers | grep certbot
sudo certbot renew --dry-run
sudo certbot certificates

The dry run contacts Let's Encrypt's staging service and performs everything except saving a real certificate. If it succeeds, real renewals should too. The last command lists each certificate, its names and its expiry date. Do the dry run again after any change to your web server configuration, DNS or firewall, since those are the usual causes of silent renewal failure.

Reload the web server after renewal

A renewed certificate on disk does nothing until the server loads it. The Nginx and Apache plugins normally handle this, but for webroot or standalone setups add a deploy hook, which runs only after a successful renewal:

sudo certbot renew --deploy-hook "systemctl reload nginx"

You can also store the hook permanently by placing an executable script in /etc/letsencrypt/renewal-hooks/deploy/. Mail servers, databases and other services that use the certificate need their own reload commands in that same hook.

Troubleshooting and monitoring

Common failures

• Connection or timeout errors: port 80 is blocked by a firewall, or the domain points to a different server.
• Unauthorized or 404 errors: the web server does not serve the /.well-known/acme-challenge/ path, perhaps because a redirect rule or deny directive catches it.
• Rate limits: Let's Encrypt limits how many certificates you can request in a period. Use --staging or --dry-run while experimenting, and see its documentation for the current limits.
• Expiry warning emails: if you receive one, renewal is failing; run sudo certbot renew and read the output.
• Proxy or CDN in front: if a CDN proxies your domain, validation may reach the CDN instead of your server. Check your CDN's SSL mode or use DNS validation.

Monitoring expiry

Automation can still fail, so add an independent check. Many uptime monitors warn when a certificate is due to expire, or you can script it with openssl as described in our server monitoring article. A certificate that expires unnoticed means browser warnings for every visitor.

Wildcard certificates and multiple servers

If you run many subdomains, a wildcard certificate may be simpler than one certificate per name, but it requires DNS validation, and the private key then protects every subdomain, so guard it carefully. If several servers need the same certificate, issue it once and distribute it securely with a deploy hook, or let each server obtain its own. Whichever way you choose, keep a record of where each certificate lives. The security page explains more about encryption on the web.

HTTPS with Zebra Hosting

On Zebra Hosting plans, free Let's Encrypt certificates are included and managed through Plesk, so there is nothing to renew by hand. Read more on the SSL page.