Catch Certificate Renewal Failures Early

Automatic certificate renewal removes a repetitive task, but it still depends on working DNS, a reachable validation route, usable credentials and successful deployment. Monitor those dependencies and the certificate actually served to clients.

Begin with an endpoint inventory. Include the main website, redirected hostnames, API services, mail gateways, reverse proxies and internal services reached through a VPN. Record where TLS terminates and who controls that certificate. A public edge certificate and an origin-server certificate are separate operational items.

Observe the endpoint independently

Use an external monitor to check the expected hostname, certificate validity and remaining lifetime. Where several addresses or regions serve the same hostname, include enough coverage to detect an instance that missed deployment. Check IPv4 and IPv6 routes where both are published.

Set alert thresholds against the certificate's actual expiry and the time required to repair a failed renewal. Do not hard-code an assumption that every certificate lasts the same number of days. Escalate repeated failures while sufficient valid lifetime remains, and route the alert outside the service being monitored.

Record the certificate issuer and identity seen by the monitor. An endpoint presenting a valid certificate for the wrong hostname still needs attention. An internal check that reaches a different proxy is not equivalent to the path customers use.

Distinguish no work, renewal and deployment

Certbot's renew documentation explains that exit status zero can mean either successful renewal or that no certificate needed renewing. A successful process status therefore does not prove that a new certificate was issued.

Track the renewal attempt and the expiry of the resulting certificate. Then check whether the application or proxy loaded it. Certbot provides deployment hooks for actions after successful issuance; use the appropriate documented integration and observe its result. Avoid treating a generic post-attempt hook as proof of successful renewal.

The read-only inventory command is:

certbot certificates

Use it on the host managing the certificates and compare the named certificate with the live endpoint. Do not include private-key contents in logs, monitoring payloads or support tickets.

Identify the validation route that can break

For HTTP-01, Let's Encrypt must reach the challenge on port 80. A proxy rule, changed webroot, new firewall or removed address can break that route while ordinary HTTPS traffic still works. For DNS-01, automation needs to create the correct DNS TXT record and allow it to become visible. The Let's Encrypt challenge documentation describes these methods and their constraints.

Write down which system owns the challenge. If DNS validation uses an API credential, record its scope, expiry and replacement procedure. Prefer a narrowly authorised validation route supported by the provider. A registrar password copied into an unattended script makes future rotation and access review unnecessarily difficult.

Include delegated challenge zones in the inventory. Someone can migrate the main website successfully while leaving a renewal dependency pointing at an old provider. Review challenge routing when DNS, hosting, firewall or proxy settings change.

Check CAA when issuance fails

CAA records constrain which certificate authorities may issue for a name. Let's Encrypt checks them before issuance, and DNS errors during the check can also block a certificate request. Its CAA documentation explains inheritance, aliases and relevant error cases.

When investigating, capture the requested names, the reported validation error and the DNS answers at that time. Check every name on a multi-name certificate. Fix the specific authorisation or DNS fault rather than repeatedly forcing renewal and hoping the next request succeeds.

Keep planned changes reversible. Preserve the previous renewal configuration and avoid replacing a still-valid production certificate with staging material during testing.

Rehearse the failure path

Certbot supports renewal dry runs, but review the configured server and hooks first. A dry run can exercise challenge integrations and hooks; it is not necessarily a read-only operation. Test deployment hooks deliberately because they are not included in the same way by default. These behaviours are documented in the Certbot guide.

Run the check during a suitable maintenance period after meaningful configuration changes. Confirm who receives a simulated monitoring alert and whether that person can access the DNS, host and certificate configuration needed to repair a failure.

Finish the review with three pieces of evidence: a working renewal route, a certificate correctly deployed to the intended endpoints, and an alert that reaches an accountable person with time to act. Keep the observed dates and scope so the next administrator can tell what was actually checked.

References

• Electronic Frontier Foundation, Certbot User Guide. Accessed 17 October 2026.
• Let's Encrypt, Challenge Types. Accessed 17 October 2026.
• Let's Encrypt, Certification Authority Authorization. Accessed 17 October 2026.