Expiry Is a Failure Mode: Drilling the Certificate Estate for the 200-Day Regime
Photo: U.S. Army Corps of Engineers Savannah District, Public domain, via Wikimedia Commons
TLS certificate expiry has always been a calendar problem until it becomes an availability problem. In 2026 the calendar has less room in it. Under the CA/Browser Forum baseline requirements, the maximum validity for publicly trusted certificates fell to 200 days this year, with further reductions scheduled for 2027 and 2029. The direction of travel is clear. Renewal is no longer an annual administrative task; it is a recurring change to production that deserves the same scrutiny as any other deployment.
For UK teams with a long tail of subdomains, load balancers, partner endpoints and forgotten marketing sites, the risk is not simply that a certificate will be renewed late. It is that nobody will know which certificates matter until one expires. The practical response is to treat certificate expiry as a rehearsed failure mode: inventory the estate, find the orphans, test the renewal path under stress, and build alerts that assume no human will be awake at 02:00.
Inventory the estate you depend on, not just the one you own
A certificate inventory built from a configuration management database will be incomplete. It will miss certificates issued by marketing teams, acquired brands, staging environments promoted to production, and third-party endpoints that your services call out to. Start with certificate transparency logs for public hostnames, then reconcile against DNS, load balancer configuration, ingress controllers, API gateways, mail servers, VPN concentrators and any service that uses mutual TLS. Include outbound dependencies: payment gateways, identity providers, address lookups and partner APIs. If your mobile app pins a certificate, that pin belongs in the inventory too.
Record more than the expiry date. For each certificate, capture the owning team, the application or journey it supports, the issuer, the renewal method, the deployment path, and the business criticality. A certificate with no named owner is not an asset; it is an incident waiting for a date.
Orphan certificates are an ownership problem
The most dangerous certificates are the ones nobody claims. They often sit on legacy subdomains, regional microsites, old campaign pages or partner callbacks. They may be valid for months, which is precisely why they are ignored until a customer-facing form fails. Use certificate transparency monitoring to find newly issued certificates for your domains, and compare that list with your inventory. Every unexplained certificate needs an owner or a decommissioning date.
This is also a governance exercise. If a team can request a certificate without registering it, the inventory will decay. Make registration part of the request path, and make the owner field mandatory. The aim is not a perfect spreadsheet; it is a reliable answer to the question: which certificates would hurt us if they expired tonight?
Rehearse the renewal path, including the boring failures
Automated renewal is not a control unless it has been tested under the conditions that actually occur. Run a canary renewal for a low-risk certificate and observe the full path: challenge completion, DNS API permissions, rate limits, private key storage, configuration reload, and propagation to every edge. Then inject failures. Expire an API token. Remove a DNS permission. Simulate an unavailable hardware security module. Block the ACME client from reaching the network. Ask what happens if the approver is on leave or the vendor portal is down.
The goal is to measure time to recover, not to confirm that the happy path works. A renewal that requires a human to click a button is a renewal that will fail at 02:00. Where human approval remains, document the break-glass route and test it. Where automation exists, confirm that it alerts on failure rather than silently retrying until expiry.
Alerts that assume nobody is watching
Expiry alerts sent to a shared mailbox are not an alerting model. They are a hope. Use synthetic checks from multiple locations to test the certificate chain actually presented to users, not just the certificate stored in a vault. Monitor certificate transparency for unexpected issuance. Build a dead-man's switch that fires if a renewal job has not run within its expected window. Route alerts to the on-call rota with a runbook that names the owner, the deployment path and the rollback step.
Set thresholds by risk rather than by habit. A tier-zero checkout endpoint needs more notice than a brochure site, but the 200-day regime reduces the slack available for manual intervention. The alert should arrive while there is still time to act without an emergency change.
A four-week drill for a 200-day regime
Week one: discover and reconcile. Pull certificate transparency logs, DNS records and load balancer configurations into one list. Week two: classify and assign. Tag every certificate by owner, journey and criticality, and flag the orphans. Week three: renew a canary through the real pipeline and record every manual step. Week four: inject two plausible failures and update the runbook from what you learn.
The success criteria are simple. Every certificate that matters has an owner, an automated renewal path or a documented manual route, and an alert that reaches a person who can act. The 200-day limit is the current constraint, not the final one. Teams that rehearse now will be better prepared when the windows shorten again.
Certificate expiry is a reliability problem dressed as administration. Treat it that way, and the date on the certificate becomes a testable control rather than a surprise.
