nginx reloaded nothing. Certbot still exited 0.<br>CertPost
Sign InSign Up
Aug 4, 2026<br>nginx reloaded nothing. Certbot still exited 0.<br>Certbot wrote a new fullchain.pem and exited 0. openssl on :443 still shows last month's notAfter. Prove disk vs wire, reload nginx, add a deploy hook.
Certbot finished the renew. The log line says success. /etc/letsencrypt/live/yourdomain.com/fullchain.pem has a notAfter about 89 days out.<br>openssl s_client against :443 still prints last month's date.<br>nginx loads certificates at start (and on reload). A successful renew on disk does nothing for visitors until something runs reload. That gap is this whole post.<br>Prove it (disk vs wire)<br>Run both. Compare the two end dates.<br># disk — what certbot wrote<br>openssl x509 -noout -enddate \<br>-in /etc/letsencrypt/live/yourdomain.com/fullchain.pem
# wire — what visitors get on :443<br>echo | openssl s_client -connect yourdomain.com:443 \<br>-servername yourdomain.com 2>/dev/null \<br>| openssl x509 -noout -enddate<br>If disk is fresh and wire is old, stop debugging ACME. The issue is reload (or the wrong server block / wrong cert path).<br>Same answer without SSH: paste the hostname into the free SSL check. Read the served notAfter. That is the wire date.<br>For the full failure map (timer, HTTP-01, rate limit, root mail), use the disk vs wire hub.<br>Fix now<br>Reload the process that terminates TLS for that name.<br># systemd nginx<br>sudo nginx -t && sudo systemctl reload nginx
# or<br>sudo nginx -t && sudo nginx -s reload<br>Re-run the wire command (or the free check). The served notAfter should match disk.<br>If wire is still old after a clean reload:<br>Confirm which binary owns :443 (ss -lptn 'sport = :443' or sudo lsof -i :443).<br>Confirm the ssl_certificate path in the server block points at the same fullchain.pem you inspected.<br>If you terminate TLS on a load balancer or another host, reload that edge, not only the app box.<br>Make it permanent (deploy hook)<br>Certbot runs scripts in /etc/letsencrypt/renewal-hooks/deploy/ after a successful renew. Put the reload there so the next renew does not depend on memory.<br>sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null Dry-run does not always exercise deploy hooks the way a real renew does. After the next real renew (or a controlled renew in a maintenance window), compare disk and wire again.<br>Optional: only reload when the renewed lineage matches hosts this box serves. Keep the first version simple: one reload after any successful renew on this machine is enough for most single-nginx boxes.<br>How you catch it off-box<br>From inside the server, every log can still say "renewed." From outside, the served cert is the only signal that matches the browser.<br>One-off: SSL checker on the public hostname.<br>Expiry-focused read: SSL expiry checker.<br>Ongoing: CertPost watches the served cert (3 free, no card) and emails at 30/14/7/1 days, plus chain and hostname breaks.<br>Watch the wire. Not only the renew log.<br>Related failures<br>Certbot says it renewed. Your server is still serving the old cert. — the full disk-vs-wire failure map: challenge, timer, mail, rate limits<br>HTTP-01 died after you forced HTTPS. — when the renew itself fails because a redirect ate the challenge<br>The certbot timer is not running. — when nothing schedules the renew at all<br>Renewal failed. Root mail never left the box. — when the errors were reported to nobody<br>Your certificate renewed. Your visitors still got the old one. — a postmortem of this exact failure in the wild<br>Too many certificates already issued. — when the retry loop burns the quota and the legitimate renewal is refused<br>Full chain check when disk dates match but browsers still warn
One check now, or every day from now on.<br>3 certificates free forever · No agent · No credit card
Start freeRun a free check
© 2026 · Kryptoplus Labs Ltd · London<br>Privacy<br>Terms<br>Cookies