Automate and verify TLS certificate renewal

Separate three different deadlines

Distinguish domain registration renewal, certificate expiry and proof of domain control. Record the authority, covered names, TLS termination point, owner and renewal procedure. A CDN, load balancer and origin server may use different certificates. Renewing a hosting subscription does not establish that each certificate is renewed.

For public TLS certificates in scope of the Baseline Requirements, maximum validity is 200 days for issuance from 15 March 2026 through 14 March 2027, then 100 days through 14 March 2029, and 47 days from 15 March 2029. These are ceilings, not universal lifetimes. An authority may use shorter periods.

Inspect the profile instead of assuming a lifetime

Let’s Encrypt publishes its own schedule: tlsserver profile at 45 days since 13 May 2026; classic profile scheduled for 64 days on 10 February 2027 and 45 days on 16 February 2028. Check the configured profile and current documentation before defining alerts. Do not describe all Let’s Encrypt certificates as already having 45-day lifetimes.

Choose an intervention margin suitable for observed validity and the actual response time of the team. A rule based on an old annual certificate could alert too late. Keep observed start and end dates in the inventory without including secrets. Expiry or a missing hostname is a concrete defect requiring action.

Test issuance and installation separately

Let’s Encrypt staging helps prepare an integration. Its certificates are not intended to be trusted by visitors’ browsers. Run that test in an appropriate environment, then verify the production journey with the expected certificate.

Include a case where renewal produces a new file but the service still presents its old certificate. Check from outside the termination point after reload or deployment. With multiple servers, inspect the different destinations. Retain hostname, date, presented certificate and connection result; a successful renewal log alone does not establish installation.

• Issuance tested in staging.
• Installation and reload verified.
• Visitor-facing certificate inspected.

Make validation reproducible

Let’s Encrypt ACME challenges demonstrate domain control: HTTP-01 uses an HTTP resource and DNS-01 a TXT record. DNS-01 also enables wildcard names. Identify DNS, routing and ACME-client dependencies before changing hosting.

A redirect, an upstream protection layer or a DNS change can break a previously working mechanism. Repeat the documented test after such changes. Name the validation owner and environment without copying access details. Retain a clear test record for the next operator.

Monitor the served result and prepare recovery

Let’s Encrypt’s integration guide includes support for ACME renewal information when available. Document the chosen mechanism, version, latest success and errors. Add an independent observation of the certificate actually served.

Decide who receives an alert, the response window and escalation if nobody responds. Recovery should cover diagnosis, installation and post-fix verification. Connect it with the incident plan and acceptance log. Avoid discovering an unavailable validation owner on the eve of expiry.