Shorter TLS certificates expose every renewal you never automated

By Greg Nowak. Last updated 2026-07-26.

Long-lived TLS certificates can make a fragile renewal process look dependable. A calendar reminder prompts someone to act. A DNS record gets changed by hand. The new certificate reaches the server, but nobody reloads the service. Because this happens only occasionally, the team usually has time to recover.

Shorter lifetimes remove that breathing room. Renewal becomes a regular production workflow, and every dependency on memory, undocumented access or an ageing script gets exercised more often. Eventually, one of those gaps reaches the live endpoint.

The shorter-lifetime schedule is already under way

The CA/Browser Forum now limits publicly trusted TLS certificates issued from 15 March 2026 to 200 days. That maximum falls to 100 days from 15 March 2027 and 47 days from 15 March 2029. Reuse periods for domain and IP address validation data also shrink: 200 days from March 2026, 100 days from March 2027 and just 10 days from March 2029.

Let's Encrypt is moving in stages too. Its opt-in tlsserver ACME profile began issuing 45-day certificates on 13 May 2026. The default profile is scheduled to change to 64-day certificates with a 10-day authorisation reuse period in February 2027, followed by 45-day certificates and a seven-hour reuse period in February 2028.

So this is no longer a distant compliance issue. The industry's 200-day limit is active, and organisations can already use a path to 45-day certificates. Let's Encrypt explicitly advises against manual renewal and recommends testing existing automation against shorter lifetimes.

Stage	What can fool you	Control to put in place	Proof it works
Discovery	A spreadsheet or the requesting team is the only record	Inventory each public endpoint, owner, issuer and deployment location	Observed certificates match the operational inventory
Validation	Someone still edits DNS or exposes a challenge manually	Automate the ACME challenge through controlled DNS or service access	A test renewal finishes without human input
Renewal	The client follows an interval designed for longer certificates	Use an ARI-capable client or lifetime-aware scheduling	Timing follows the certificate lifetime and CA guidance
Deployment	Files are updated, but the service continues serving the old certificate	Use a deploy hook to install the certificate and reload the dependent service safely	The public endpoint presents the new certificate and correct chain
Monitoring	The renewal job succeeds, but nobody checks the endpoint	Monitor live certificate expiry independently	A failed renewal or stale deployment produces an actionable alert

The renewal path is only automated when discovery, validation, issuance, deployment and independent verification all work together.

A renewed file is not a deployed certificate

One of the easiest gaps to miss appears after successful issuance. The ACME client obtains a certificate and updates the files on disk, so the renewal job looks healthy. Meanwhile, a web server, reverse proxy, load balancer or application may keep presenting the previous certificate because it never reloaded its configuration.

Certbot separates these parts of the lifecycle. Pre- and post-hooks run around renewal attempts. A deploy hook runs only after successful issuance or renewal, which makes it the right place to install converted files, publish a certificate to another component, or reload the service that uses it.

There is another small but important detail: Certbot documents that a zero exit status can mean either that renewal succeeded or that no certificate was due for renewal. A wrapper that treats every zero as proof that a new certificate reached production is giving false assurance.

The test therefore needs to continue past the job log and the filesystem. Connect to the public endpoint and inspect what it actually serves: identity, expiry, issuer and chain. That check exposes stale processes, incomplete propagation and configurations pointing to a different file from the one the ACME client updated.

Start with the certificate estate

Automating the most obvious Linux web server is worthwhile, but it does not tell you whether the rest of the estate is covered. DigiCert's guidance treats discovery, renewal, deployment, monitoring and policy as a single workflow across different environments. It recommends finding certificates and confirming their deployment locations before shorter lifecycles turn omissions into outages.

A useful discovery pass includes websites, APIs, proxies, load balancers, containers and vendor-managed systems. For each certificate, record the endpoint, responsible owner, issuing CA, renewal client, validation method, deployment target and monitoring path.

Then look for the awkward cases: manually issued certificates, manual Certbot plugins without authentication hooks, appliances without ACME support, credentials still tied to departed staff, and vendor portals that require a human upload. The useful output is not a bigger spreadsheet. It is a clear list of certificates that cannot renew unattended and endpoints whose deployed state cannot be checked independently.

Fixed renewal schedules will become brittle

Hard-coded timing ages badly when certificate lifetimes change. Let's Encrypt notes that a client configured to wait 60 days before renewing will fail when given a 45-day certificate. A proportional threshold is safer, but ACME Renewal Information, or ARI, removes more guesswork by allowing the CA to provide a suggested renewal window.

Let's Encrypt's published account of Shopify's ARI implementation shows the operational difference. A fixed threshold could not adjust to a changed certificate lifetime, coordinate renewal load with the CA or react quickly to revocation. With ARI, the system requests the suggested window, chooses a time inside it and continues polling for changes. The CA can then bring renewal forward when an urgent replacement is needed.

The practical job is to identify every ACME client and version, confirm ARI support, enable it where necessary, and remove logic built around assumptions inherited from 90-day certificates. Pay particular attention to older clients and custom integrations. They may be automated in appearance while still relying on fixed thresholds.

Validation has to run without supervision

As certificate lifetimes and authorisation reuse periods contract, organisations must prove domain control more frequently. Let's Encrypt identifies validation as one of the hardest parts of automatic issuance. Current challenges require a client to serve an HTTP token, answer a TLS handshake or update a DNS TXT record.

That makes DNS automation part of availability engineering. API credentials need enough scope to update the required records, but no more. The renewal path must allow for DNS propagation and make authentication failures visible. If validation still needs a person, renewal is not automated; the surrounding steps simply happen to be scripted.

Exercise the failure paths

Certbot supports dry-run renewals and recommends using them to confirm that future renewal will work. Run those checks regularly, and include applicable deploy hooks when the hooks change. One successful test is not permanent evidence: DNS permissions, file paths, service names and infrastructure ownership all move over time.

Independent expiry monitoring is the final safety net. It should inspect the certificate presented by the endpoint, rather than trusting the ACME client's local state. Alerts need enough lead time for investigation and should distinguish between a failed renewal and a successful renewal that never made it into service.

The immediate task is not to process certificates faster by hand. It is to make the whole path repeatable: discover, validate, issue, deploy, verify and alert. Greg can help map the certificate estate, find manual and non-ACME paths, upgrade clients for ARI, implement controlled validation and deployment hooks, verify the chains served after renewal, and add independent expiry and failed-renewal monitoring. With those pieces in place, shorter lifetimes become a manageable operating cadence instead of a recurring availability risk.