Let's Encrypt And ACME Automation

Until 2015, getting a TLS certificate was annoying. The process:

• Pay a CA $50–$300/year;
• Fill out a web form with your business details;
• Email back and forth with a CA verification analyst;
• Receive the cert as a .crt file;
• Manually install it on your server (debug intermediate chain issues);
• Set a calendar reminder for a year from now to do it all over again.

Most small sites just didn't bother. They ran on plain HTTP. In 2015, less than half the web was encrypted. Today it's about 94%, and the single biggest reason is Let's Encrypt.

What Let's Encrypt Changed

Let's Encrypt was launched in 2016 by the Internet Security Research Group (ISRG) with one mission: make TLS certificates free, automated, and universal. Three properties:

• Free — no payment, no business verification, no friction;
• Automated — issued in seconds via a protocol called ACME, no humans involved;
• Short-lived — 90-day max validity, forcing people to set up automation from day one.

As of 2026, Let's Encrypt has issued over 5 billion certificates and secures most of the internet's small and medium sites. Major CDNs use it. Free hosting platforms use it. Hobby projects use it. Even big enterprises use it for internal services.

ACME — The Automatic Certificate Management Environment

The protocol Let's Encrypt invented and standardized in RFC 8555. The basic flow:

• Step 1 — Your ACME client tells the CA "I want a cert for example.com";
• Step 2 — The CA replies "Prove you control the domain. Here are some challenges you could solve";
• Step 3 — Your client picks a challenge and completes it;
• Step 4 — The CA verifies and issues the certificate.

The entire flow takes about 30 seconds when everything's set up. No emails, no humans, no forms.

The Three Domain Validation Challenges

ACME supports three ways to prove you control a domain:

HTTP-01 — the most common, simplest setup:

• The CA gives your client a random token;
• The client puts the token at http://example.com/.well-known/acme-challenge/<token>;
• The CA fetches that URL and checks the content;
• Pass → cert issued.

Requires port 80 to be reachable from the CA. Doesn't work for wildcards.

DNS-01 — required for wildcard certs, also useful when port 80 isn't accessible:

• The CA gives your client a token;
• The client adds it as a TXT record at _acme-challenge.example.com;
• The CA queries DNS and checks the record;
• Pass → cert issued.

Requires programmable access to your DNS — every major DNS provider has an API. The downside is propagation delay (sometimes 30+ seconds), but DNS-01 is the only way to issue wildcard certs like *.example.com.

TLS-ALPN-01 — variant of HTTP-01 done over TLS on port 443:

• The CA initiates a TLS handshake with a special ALPN value;
• Your server responds with a specially-crafted self-signed certificate containing the token;
• Pass → cert issued.

Useful when port 80 is blocked but port 443 is available. Less commonly used in practice.

The Tools You'll Actually Use

You don't write ACME by hand. Pick one of these clients:

• Certbot — the official EFF-maintained client. Python. Battle-tested. Default install on most Linux distros. apt install certbot, certbot --nginx, done;
• acme.sh — a pure-shell client. No dependencies. Great for minimal containers. Widely loved for its simplicity;
• lego — written in Go. Single binary. Popular in Docker / Kubernetes contexts;
• Caddy — a full web server with ACME built in. Set email in the config, certs just appear. Magic;
• Traefik — reverse proxy with built-in ACME. Same magic, container-native.

If you're starting fresh in 2026, Caddy is the easiest. Drop a 5-line config, your site has automatic HTTPS, free certificates, renewals, redirects, the works. If you're on an existing Nginx setup, Certbot is the well-trodden path.

A Minimal Working Example — Certbot With Nginx

The complete setup, start to finish:

# Install Certbot with the Nginx plugin
sudo apt install certbot python3-certbot-nginx

# Issue a cert + auto-edit the Nginx config
sudo certbot --nginx -d example.com -d www.example.com

# Test renewal (does a dry run)
sudo certbot renew --dry-run

# The renewal cron job is already installed by the package.
# You're done.

That's it. Three commands. The cert is valid, Nginx is configured, HSTS is added if you ask for --hsts, renewals happen via systemd timer or cron.

Renewal — The "Just Works" Pattern

Certbot's installer drops a renewal task that runs twice a day. Each run checks all your certs. If any cert expires in less than 30 days, it renews automatically. If not, it does nothing.

The pattern works for 90-day certs. It still works for 47-day certs. It works for 6-day certs if you set it to run more often. The whole point of ACME is that the renewal interval is no longer your problem.

ARI — ACME Renewal Information is a 2024 ACME extension where the CA tells the client when to renew, dynamically. The CA can say "this cert was issued during a known issue, renew it now" or "renew in 30 days from now." Certbot 4.1+ supports it. With ARI, even certificate revocations effectively become automatic re-issuance.

What To Monitor

Even with automation, things break. Set up these alerts:

• Cert expires in less than 14 days — your automation has failed silently somewhere;
• TLS handshake errors on your server logs — chain issues, weak protocols, misconfigurations;
• New certs in CT logs for your domain that you didn't request — possible mis-issuance.

Tools to use: Uptime Robot, Better Uptime, CrowdSec, Cert Spotter, or just a simple cron + openssl s_client | openssl x509 -noout -dates script that pages you.