The site goes down Tuesday at 9:01 AM: NET::ERR_CERT_DATE_INVALID. The last Let's Encrypt certificate expired at midnight. Certbot runs on the server — logs show HTTP-01 failures for six weeks: firewall closed port 80 after hardening, and nobody alerted on certificate date, only HTTP 443 ping.
ACME automates issuance — not governance. Successful renewal in certbot does not guarantee the certificate is served to visitors or that monitoring of real expiry is in place.
ACME flow and failure points
Standard cycle:
- Agent (certbot, lego, integrated Caddy) requests challenge.
- Let's Encrypt validates HTTP-01 or DNS-01.
- Certificate issued; agent installs and reloads web server.
| Challenge | Use case | Common failure |
|---|---|---|
| HTTP-01 | VPS, public origin on port 80 | Port 80 closed, redirect loop |
| DNS-01 | Wildcard, private origin | Expired or misconfigured DNS API token |
Use Let's Encrypt staging environment for tests — without consuming production quota.
Renewal log "success" without
nginx -s reloadleaves old certificate active — or worse, updated file the server does not read.
For maintainable TLS configuration beyond renewal, see Configuring TLS.
Certbot, cron and deploy hooks
On Debian/Ubuntu, verify certbot.timer systemd is active: systemctl status certbot.timer.
Add hook in /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh:
#!/bin/sh
nginx -t && nginx -s reload
On multiple servers, sync certificates or coordinate reload per node after renewal.
Multi-domain, SAN and wildcard
SAN certificate covers www and apex — both names must pass challenge. Wildcard *.example.com requires DNS-01: automate via registrar or CDN API (Cloudflare, OVH, etc.).
During host migration, reissue before cutting old origin — plan 48 hours overlap.
Compare Let's Encrypt or paid certificate depending on B2B or extended validation constraints.
Expiry monitoring
Set up at minimum:
ssl_exporterprobe withdays_until_expiry < 21alert- Blackbox probe on real TLS connection
- X.509 date inventory per production domain
Separate renewal failure alert (certbot logs) from expiry alert (certificate presented to browser). SSL Labs does not replace Prometheus alert or cron reading certbot certificates.
If CDN terminates TLS in front of origin, track two dates: edge certificate and origin certificate.
Managed hosts and integrated ACME
Panels (Plesk, cPanel, Infomaniak manager) often handle Let's Encrypt natively — verify auto-renewal is enabled and admin email is current.
The peak: automation without closed loop
Here is what gets forgotten when installing certbot once and walking away.
Monitoring renewal means dry-run plus expiry monitoring plus reload hook — not just installing certbot.
Decide and move forward without blind spots
In half a day you can close the ACME loop:
- Verify certbot timer or cron is active and documented.
- Add post-renewal reload hook tested in real conditions.
- Schedule monthly dry-run with alert on failure.
- Configure expiry alert under 21 days on served certificate, not disk only.
- Document challenge dependencies (port 80, DNS API, firewall whitelist).
- Write "expired certificate" runbook: forced renewal, reload, chain verification.
Compare hosts with integrated Let's Encrypt via the directory and comparison tool.
Frequently asked questions
How often does Let's Encrypt renew?
Certificates valid 90 days; automatic attempts about 30 days before expiry. Cron or systemd timer must be verified — not automatic on all installations.
HTTP-01 or DNS-01?
HTTP-01 if port 80 is public and stable. DNS-01 for wildcard, private origin or complex routing — with automated DNS API and monitored tokens.
How to monitor expiry?
Alert on certificate date presented to clients under 21 days. Complement with monthly dry-run. Let's Encrypt email alone is insufficient.
Renewal OK but TLS broken on site?
Web server reload after renewal is often missing. Automate deploy hook and test after every configuration change.
Let's Encrypt renews often — your stack must prove it serves the right certificate on time.