Guide
Reload nginx after Certbot renew
After certbot renew, run nginx -t and nginx -s reload so workers present the new fullchain on port 443.
Updated Apr 2, 2026 808 words
Certbot renew without nginx reload leaves workers serving the previous fullchain—always nginx -t then reload.
When this happens
PEM mtimes update but openssl s_client serial unchanged. Worker_connections limits during reload storms show as dropped handshakes mistaken for still-expired certs in synthetic checks. Peak traffic weeks expose reload gaps because teams fear nginx signal impact and defer hook testing until expiry week, when rollback options are narrower.
Dockerized nginx never receives SIGHUP after host certbot runs. Sidecar mesh certs are unrelated—confirm you reloaded the public ingress nginx instance. Blue/green nginx plus shared disks means reload on active color while keepalived promotes passive without reload.
First response
After certbot renew, run nginx -t and nginx -s reload so workers present the new fullchain on port 443.
Searches for reload nginx after certbot renew usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.
For Reload nginx after Certbot renew, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.
Nginx masters keep certificates memory-mapped until signal reload. Certbot renew without nginx -s reload yields successful logs and angry users. Validate with external openssl immediately after every renewal event. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius. Pause destructive retries until you can cite the last Boulder error type and the challenge mechanism in use; random package reinstalls rarely fix presentation gaps.
See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.
Why renewal failed
nginx reads certificate files on reload, not when certbot touches symlinks. When using symlinks, ensure reload runs after sleep 1 if your tooling atomically swaps directories—some scripts race nginx mid-rename. nginx reload discipline should be as mandatory as backup restore tests.
Failed configtest in deploy-hook aborts reload while renew succeeds. Stream (TCP) TLS and HTTP TLS use different directives—renewing HTTP fullchain does not update stream cert paths. Container and bare-metal mixes need hooks explicit about which nginx instance reloads.
Multiple nginx instances on blue/green need coordinated hooks. Include nginx -T excerpt showing ssl_certificate path in change tickets. Escalate with timestamps, hostnames, and serial comparisons attached so the next engineer does not repeat already-failed renew attempts.
ssl_certificate paths usually symlink into live; nginx reads file on reload, not on renew touching disk. Multiple workers need graceful reload to pick up new inode. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs. Nginx reload discipline is cheaper than emergency OV purchase; teach teams that PEM mtimes lie as often as certificate files on disk.
Not solved by certonly without deploy hook when using webroot auth. Reload omissions persist across teams because disk checks feel sufficient; bake external serial verification into the definition of done for every renewal change.
Common causes
These patterns drive most reload nginx after certbot renew tickets. They explain why automation logs look green while browsers or APIs still break.
Forgot deploy-hook after switching from nginx plugin. Configuration management that notifies reload only on content hash changes may skip reload when certbot updates symlink targets in place without touching the path string in nginx.conf.
Docker nginx without reload signal to container. Multiple nginx packages on one host—vendor nginx versus distribution nginx—mean hooks reloading the wrong binary while customers hit the other listeners.
Configtest fails so hook aborts reload. Ansible copy module skips reload notification when file checksum unchanged despite renewed symlinks upstream.
Diagnose
Check hook logs and compare serials. Split the incident into certbot success criteria and nginx presentment criteria; most tickets merge them incorrectly and close while strangers still see stale notAfter values on the same hostname.
nginx -t && nginx -s reload
grep deploy-hook /var/log/letsencrypt/letsencrypt.log | tail
Check letsencrypt.log hook exit; nginx error log for SSL file read errors. Check master PID start time versus reload timestamp to confirm signal delivery. When using unix socket activation, confirm reload signals reached the socket unit actually binding :443.
Fix step-by-step
Follow this sequence for reload nginx after certbot renew. Capture command output after each step so the next responder can pick up without rerunning destructive changes.
- Add certbot deploy-hook with nginx -t guard.
- Point ssl_certificate at live fullchain paths.
- Run dry-run renew to test hook.
- Production renew during low traffic if needed.
- External openssl serial check.
- Confirm both IPv4 and IPv6 listeners reloaded.
- Update automation docs for new nginx paths.
- Monitor serial nightly.
- Archive redacted ACME logs and openssl transcripts in the ticket before closing.
- Schedule a follow-up dry-run before the next natural renewal window.
Verify the live certificate
OpenSSL
echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer
Replace HOST with the public hostname on the certificate. Run the same command after any reload or deploy change; acceptance means notAfter moved forward and serial changed versus the incident-opening capture.
How to read the output
Serial mismatch proves reload gap. When comparing serials, hit the same IP address customers resolve and pass the exact Server Name the vhost matches; shared hosting default certificates on the same address will mislead if SNI is omitted from openssl s_client.
curl
curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'
Replace HOST with the public hostname users request.
Roll out and verify
Add deploy-hook running nginx -t && nginx -s reload. Standardize on absolute paths in ssl_certificate directives and document which unit file owns production traffic before writing certbot hooks.
certbot renew --dry-run verifying hook. For large configs, consider nginx -s reopen only when reload docs say safe for your module set. Automate post-renew verification that queries both certificate serial and issuing issuer to detect partial chain copies.
Monitor serial nightly. Runbooks should forbid marking renew complete until at least one external synthetic and one manual openssl agree on the new serial. Publish a short post-incident note listing which hop served stale TLS and which command proved the fix so the next renewal inherits a checklist.
What to automate
Hook failure alerts should be as loud as renew failure alerts. Alert when PEM mtime changes but external serial does not within five minutes.
ssldays confirms reload actually changed what users negotiate on 443. ssldays closes the loop nginx operators most often forget after certbot.
Frequently asked questions
openresty?
Same reload semantics apply—use openresty binary in hooks. Log nginx -t and reload timestamps in UTC.
Zero downtime?
Reload is graceful for most sites; test long-lived HTTP/2 streams if critical. Log nginx -t and reload timestamps in UTC.
certbot nginx plugin?
It can reload when used for issuance; webroot mode still needs hooks. Log nginx -t and reload timestamps in UTC.
Does reload affect QUIC or HTTP/3?
nginx reload behavior depends on build modules; some QUIC endpoints need validation after renew. Test HTTP/3 handshakes if you serve them to production. stream {} TLS may need separate reload signals documented in your hook.
Monitor this hostname on a schedule
Live certificate checks and renewal reminders — not guesswork from PEM files.