Maintain TLS renewal with Certbot tests, service reloads and external checks

Certificate renewal is a workflow: prove control of a hostname, issue a certificate, store it safely and make the live service use it. A green scheduled job covers only part of that workflow. Maintenance should verify the public certificate, the validation path and the reload behavior before an expiry warning becomes an outage.

Find the certificate manager and every endpoint it owns

sudo certbot certificates
systemctl list-timers --all | grep -Ei 'certbot|acme'
systemctl list-unit-files | grep -Ei 'certbot|acme'

Package, snap and third-party installations can use different unit names and paths. Inspect the actual units instead of assuming certbot.timer is always present. Record the certificate names, covered domains, challenge method and services that consume each certificate.

Include CDN edges, reverse proxies and mail services where relevant. A website certificate may be independent of the certificate presented by IMAP or SMTP. Replacing one certificate file does not prove that every listener uses it.

Check the live certificate from outside the server

openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error </dev/null

openssl s_client -connect example.com:443 -servername example.com \
  </dev/null 2>/dev/null |
  openssl x509 -noout -issuer -serial -dates

Compare these results with the intended certificate files. If Certbot reports a recent certificate but the public serial or expiry is old, investigate an unreloaded service, an incorrect path, a stale load-balancer node or a separate CDN certificate. Test IPv4 and IPv6 paths where both are published.

The inspection pipeline can still display certificate information when validation would fail. Treat the first command as the trust check and the second as a way to compare public details. Do not use an insecure curl option to make an expiry monitor appear healthy.

Rehearse validation and understand the challenge

sudo certbot renew --dry-run

Read the complete result and identify which lineage failed. HTTP validation needs the challenge URL to reach the correct responder; unexpected redirects, CDN rules, authentication gates and an outdated AAAA record can break that route. A general home-page request is not proof that the challenge path is reachable.

DNS validation requires the appropriate TXT record and, when automated, credentials with sufficient DNS access. Keep API credentials protected and scoped as narrowly as the provider permits. A certificate created with a manual DNS challenge does not become automatically renewable unless the process has the required automation.

Verify the deployment hook rather than assuming renewal reloads everything

A successful issuance writes certificate material, but a long-running service may keep its previous certificate in memory. Inspect existing Certbot deploy hooks and service integration before adding another. Use a deploy hook for the services that need the new material, with a configuration check and failure reporting appropriate to that service.

# Choose the installed web server; do not run both branches blindly.
sudo nginx -t
sudo systemctl reload nginx

# Apache on Ubuntu, when Apache is the service in use:
sudo apache2ctl configtest
sudo systemctl reload apache2

These are active service operations, so run the relevant branch only after the configuration check succeeds. A Certbot dry run does not normally execute deploy hooks unless explicitly requested by supported options. A successful dry run therefore does not by itself verify every reload action or application-specific certificate copy step.

Read the actual scheduler and renewal logs

systemctl status certbot.timer --no-pager
sudo journalctl -u certbot.service --since '7 days ago' --no-pager
sudo ls -l /var/log/letsencrypt/

Adapt the unit names to the inventory; a missing conventional unit does not prove that a snap-managed timer is absent. Look for challenge failures, DNS API permission errors, rate limits and hook failures. Avoid repeatedly forcing live issuance while debugging, because certificate authorities impose rate limits.

Monitor a meaningful success signal and age as well as a process exit status. A job that never ran can leave no failure entry. External monitoring should warn early enough to investigate and still leave a workable maintenance window.

Close the loop with a renewal runbook

Document the owner, manager, challenge dependencies, credential location, reload actions and public verification command. Set alerts for the endpoint customers use, and route them to a monitored channel. Update the runbook when DNS, a CDN or a load balancer changes.

After a real renewal, confirm the new public serial and expiry, the trusted chain and representative application requests. Retain private keys with appropriate access controls and never attach them to a public issue. The useful evidence for a support request is the hostname, observed expiry, listener address and relevant redacted renewal error.

Primary documentation

• Certbot user guide
• OpenSSL TLS client reference
• systemd journalctl reference