Shorter TLS Certificates Need a Renewal Window Audit

The dangerous TLS certificate is not the one with a short lifetime. It is the one attached to automation nobody has watched succeed in two years.

That distinction matters now. Let’s Encrypt switched its opt-in tlsserver profile to 45-day certificates on May 13, 2026. Its default certificates are scheduled to shrink from 90 days to 64 days on February 10, 2027, then to 45 days on February 16, 2028. Most well-maintained ACME setups should adapt without drama. A forgotten cron job that waits 60 days, a manual DNS challenge, or a deploy hook that stopped reloading the proxy will not.

The useful response is not to renew everything early. It is to audit the whole renewal path: decision, validation, issuance, deployment, and monitoring.

The old calendar is becoming a liability

A 90-day certificate made some brittle schedules look healthy. A job hardcoded to renew every 60 days could fail once, run again later, and still leave time for a human to notice. With a 45-day certificate, that same schedule does not merely have less margin; it misses the certificate’s entire lifetime.

Let’s Encrypt recommends clients use ACME Renewal Information, or ARI, when possible. Without ARI, it says renewal at roughly two-thirds of the way through the current certificate’s lifetime is acceptable. That means the correct timing should be derived from the certificate actually issued, not from an old assumption that every certificate lasts 90 days.

This is an inventory problem before it is a configuration problem. The same lesson applies when a kernel feature works on one host and fails on another: you need to know what is really running. CyganLabs recently made that case in Copy Fail Is a Host-Kernel Inventory Problem. For certificates, the hidden variables are the issuer, profile, ACME client, version, scheduler, challenge method, deployment target, and alert path.

ARI replaces guesswork with a renewal window

ARI is an extension to ACME standardized as RFC 9773. It lets a certificate authority publish a suggested renewal window for a specific certificate. A compatible client can choose a time inside that window and tell the CA which certificate the new order replaces.

That does three useful things.

First, the renewal decision follows the certificate authority’s current guidance instead of a fixed local threshold. That makes lifetime changes less brittle. Second, the CA can spread requests across time rather than receiving a synchronized pile of renewals. Third, it gives the CA a way to recommend earlier renewal in an exceptional situation such as a mass-revocation event.

ARI is coordination, not a substitute for working automation. The client still has to check the renewal information, complete domain validation when required, obtain the certificate, install it in the right place, and make the serving process use it. A healthy ARI response cannot repair expired DNS credentials or a broken reload hook.

Client behavior also differs. Let’s Encrypt tells operators to consult their client documentation because ARI support and configuration vary. Current Caddy documentation says an issuer’s ARI window can override Caddy’s locally configured renewal_window_ratio. Certbot’s current documentation bases renewal on the issued certificate’s lifetime—normally when less than one-third remains—and recommends running certbot renew regularly. The important question is not “Do I use Certbot or Caddy?” It is “Does the version I actually run make renewal decisions from current lifetime information or ARI, and have I seen it finish the entire path?”

Build a certificate-renewal inventory

Start with every public endpoint you operate, including the boring ones: hypervisor consoles, backup dashboards, media servers, webhook receivers, test subdomains, and services reachable only through a private overlay. A certificate expiring on a low-traffic admin page is still an outage; it is merely an outage with fewer witnesses.

For each endpoint, record:

the hostname and certificate issuer;
the current certificate’s notBefore and notAfter dates;
the ACME client and installed version;
where its renewal job is scheduled;
whether it supports ARI and ACME profile selection;
the validation method: HTTP-01, DNS-01, TLS-ALPN-01, or something else;
where the renewed certificate is written;
how the web server, proxy, or appliance reloads it; and
which alert proves a failed or late renewal will reach a person.

Do not assume the certificate on disk is the certificate on the wire. A successful ACME order followed by a failed copy, container mount, or proxy reload can leave the old certificate serving traffic.

One quick external check is:

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

Replace example.com with the endpoint being tested. This shows what the TLS service is presenting. It does not prove that the next renewal will work, but it catches the common gap between “a new file exists” and “clients receive the new certificate.”

Test the path, not just the command

Let’s Encrypt strongly recommends testing against its staging environment before production. The ACME v2 staging directory is https://acme-staging-v02.api.letsencrypt.org/directory. Staging uses untrusted test roots, so a staging certificate should fail ordinary browser trust checks; that is expected. It also requires a separate ACME account, which Certbot handles automatically when invoked with --test-cert or --dry-run.

A useful renewal test should prove all of these transitions:

The scheduler starts the correct client with the expected configuration.
The challenge succeeds with current network paths and credentials.
The client obtains a replacement certificate.
Deployment puts the new certificate and key where the serving process expects them.
The process reloads or otherwise begins serving the replacement.
Monitoring observes the new expiry and clears any warning state.

If the client supports ACME profile selection, the 45-day tlsserver profile is a practical noncritical test target. The Let’s Encrypt directory object is the canonical source for which profiles are currently available, so check it rather than assuming a blog post or old client release note still describes production. The shortlived profile lasts 160 hours and is explicitly intended for operators who fully trust their automation; it is a stress test, not a fashionable default.

Testing should be repeatable. A one-time manual DNS edit proves that a person can issue a certificate, not that the system can renew one at 3:00 a.m. If DNS automation is required, verify the least-privileged credential, record ownership, propagation behavior, and cleanup path. If HTTP validation is required, verify that redirects, proxies, firewall rules, and container routing still allow the challenge.

Monitor the failure margin

Shorter lifetimes increase the frequency of renewal, but Let’s Encrypt says existing renewals are exempt from the rate limits that govern issuance for new domain names. Operators should not “solve” the transition by requesting blanket rate-limit increases. The operational risk is more likely to be a broken renewal path than an ordinary renewal exhausting issuance limits.

Monitor at least two things: days remaining on the certificate actually served, and the result of the renewal job. Either signal alone is incomplete. Expiry monitoring may catch a problem late; a green job status may hide a deployment that kept serving the old file.

Choose alert thresholds from the shortest lifetime you use and the time your team realistically needs to recover. As an operating rule, the first alert should leave room for multiple automated retries and a normal human response window. A later page should mean “intervene now,” not “begin wondering who owns TLS.”

Also inspect renewal volume. ARI is meant partly to distribute load, but an unexpected burst can reveal cloned schedules, duplicated clients, or a fleet that all lost state at once. Quiet automation is good. Invisible automation is merely quiet until it expires.

What to do before 2027

You do not need to wait for the default profile to shrink. Pick one representative endpoint and complete the audit now:

Identify the live certificate, client, version, scheduler, and challenge method.
Confirm whether that installed client supports ARI and how it behaves when ARI is unavailable.
Run a supported staging or dry-run workflow.
Verify deployment by inspecting the certificate served over the network.
Confirm expiry and job-failure alerts reach the right person.
Repeat for the rest of the inventory, prioritizing manual challenges and fixed-interval jobs.

The change from 90 days to 45 is not primarily a certificate problem. It is a test of whether “automatic” still means observed, repeatable, and owned. Shorter lifetimes simply make the answer arrive sooner.