Let's Encrypt: Free TLS Certificates, Managed Right

There was an era — not even that long ago — where making a website show a padlock meant buying a certificate from a vendor, proving you owned the domain through a dance of emails and phone calls, and paying a few hundred dollars for the privilege. The certificate would last a year or two, everyone would forget about it, and then one morning browsers would start screaming at your customers.

Let's Encrypt killed that era. Since 2016, it's issued well over a billion certificates at exactly zero cost, using a protocol — ACME — that verifies you control a domain and hands you a 90-day certificate with no human in the loop. Short-lived certificates used to sound like a downgrade. They're the opposite: short lifetimes mean a leaked key dies fast, and automation means the shortness costs you nothing.

The three pieces of doing it right

1. Get the certificate the boring way

On any mainstream VPS, the canonical path is certbot with your web server's plugin:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot edits your server config, installs the certificate, and — this is the part people miss — writes the auto-renewal config while it's at it. If you installed it manually and renewal "should work," you don't have TLS management. You have a countdown.

2. Verify renewal actually works — before you need it

Let's Encrypt gives you a dress rehearsal flag:

sudo certbot renew --dry-run

That command talks to the staging servers, runs the full validation dance, and tells you whether your renewal will work in 60 days when it counts — without touching your real certificate or hitting production rate limits. Run it the day you set up. The people whose sites die from expired certs are almost always the ones who saw "auto-renewal configured" in some installer output and never asked it to prove itself.

3. Reload the web server after renewal

A fresh certificate file on disk does nothing until the web server loads it. Certbot's nginx and Apache plugins handle the reload; the webroot method doesn't. If you went webroot (the right choice for complex setups), add a deploy hook:

sudo sh -c 'echo "#!/bin/sh
systemctl reload nginx" > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh'

Now every successful renewal reloads nginx automatically. New cert served, zero hands on keyboards.

The renewal trap that gets everyone

Here's the failure mode we've cleaned up on more servers than we can count, and it has a shape: renewals that worked for months, then silently stopped.

The cause is almost never certbot. Certbot renews just fine. What breaks is the validation path — the route Let's Encrypt's servers take to reach the little token file your server serves during renewal. Along comes a security hardening pass: an IP allowlist here, a geo-block there, a new firewall rule. Each one perfectly reasonable. And each one quietly blocking the /.well-known/acme-challenge/ path that validation depends on.

The failure is invisible by design: certbot retries on its schedule, fails quietly, and the first human who notices is the one staring at a browser warning three weeks later. Certificates are 90 days now — you get 60+ days of silent failure runway before anything visibly breaks. That's not a safety margin; that's an alarm that doesn't ring.

The defense is boring and absolute:

• Carve out ACME before hardening. If you add access rules to a vhost, add an explicit location ^~ /.well-known/acme-challenge/ { allow all; } carve-out first. Validation must always be reachable, even from IPs you've never heard of.
• Monitor expiry, not renewal. A weekly check of days-remaining on your live certificate is the alarm that actually rings. Under 21 days = investigate now. Renewal success logs can lie; a countdown clock cannot.
• One certificate per server, all SANs on it. Bundling example.com, www, and your app subdomains into one cert is tidy — just remember that means one failed domain fails the whole renewal. If a subdomain dies or gets locked down, the renewal for every name on that cert dies with it.

What "managed" should mean

TLS management isn't the install. It's the promise that on some ordinary Tuesday morning in month seven, your certificate renews itself, nginx reloads, and nobody notices — because someone set up the carve-outs, the hooks, and the expiry monitor back when everything was fresh and working.

"Auto-renewal isn't a feature you enable. It's a pipeline you verify — and then keep watching."

Our Let's Encrypt engagements end with the same proof point: certbot renew --dry-run passing, deploy hooks tested, expiry monitoring wired to an alert channel. Free certificates are great. Free certificates that never silently die are the actual product.