Summary

  • Public TLS certificate validity is capped at 200 days in the current CA/Browser Forum interval, then 100 days from March 2027 and 47 days from March 2029.
  • The useful success measure is not “certificate issued”. It is the share of intended termination points externally observed serving the approved replacement with enough remaining time to recover from failure.

Imagine a central certificate service completing an ACME order at 02:00. The dashboard turns green. Most load balancers receive the new certificate. One regional API gateway and one mail endpoint do not. Nothing failed in issuance, yet the organisation has not completed renewal. It has created two clocks: the certificate authority’s record and the fleet’s real state.

Shorter certificates make that gap more expensive. The CA/Browser Forum’s current Baseline Requirements cap subscriber certificates issued from 15 March 2026 to before 15 March 2027 at 200 days. The maximum becomes 100 days in 2027 and 47 days in 2029. Reuse of domain-name and IP-address validation data also tightens, reaching ten days in 2029.

This schedule does not say that every certificate must last the maximum. Let’s Encrypt already enabled an opt-in 45-day tlsserver profile in May 2026. It plans shorter defaults in later stages and asks subscribers to verify that their automation is compatible.

A shorter certificate is a control loop, not a smaller file

The immediate arithmetic is easy: shorter validity means more renewals. The operating consequence is harder. Each cycle depends on an intact chain of authority and execution: a known identifier, a valid domain-control method, a usable ACME account, a client that can order, a distribution path that can deploy, a service that can reload, and an external observer that can confirm the new result.

RFC 8555 automates much of that chain. It also makes the authority boundary explicit. The ACME client signs requests with an account key. Within the account’s scope, control of that key can enable issuance, revocation, account changes and key rollover. Renewal automation therefore concentrates useful authority. Treating the account key as a cron-job detail understates the business decision embedded in it.

The same is true of deployment. An ACME server can issue a certificate without knowing every reverse proxy, ingress controller, appliance, CDN edge or mail service that should present it. A secret store can contain the new bytes while a long-lived process continues serving the predecessor. A central inventory can contain a hostname while a forgotten termination point is absent from the inventory entirely.

These are different failure states. A serious system records them separately instead of compressing them into one green renewal event.

ARI moves the window; the subscriber still owns replacement

RFC 9773 defines ACME Renewal Information. A supporting certificate authority can publish a suggested renewal window, and a client can identify the certificate it intends to replace. The design helps CAs smooth demand and signal early renewal when exceptional circumstances require it.

ARI is valuable because fixed rules age badly. A static “renew 30 days before expiry” instruction can become nonsensical when the certificate itself lasts 45 days. A suggested window lets timing move without every subscriber hard-coding the CA’s current product.

Yet ARI does not close the subscriber’s control loop. It does not prove that a new certificate was installed, that the correct chain is served, that every intended edge changed, or that an external client can complete a handshake. It coordinates the start of replacement. Completion remains an observed fleet state.

Let’s Encrypt’s integration guidance reflects this distinction. It recommends checking ARI at least twice daily, retaining a lifetime-based backstop, spreading large fleets into small renewal runs and randomising schedules. Its March 2026 account of Shopify’s ARI adoption describes stored renewal windows and repeated polling rather than one fixed threshold. That is an attributed operating example, not a universal result.

The scarce asset is recovery time

Short validity reduces how long stale credentials can remain accepted. It also reduces the calendar available to diagnose a broken challenge, expired account credential, rate-limited client, failed secret sync, incompatible reload or missing endpoint.

The key management variable is therefore not renewal frequency by itself. It is usable recovery margin: the time between the first failed attempt and expiry after allowing for detection, ownership, repair, redeployment and independent verification.

A fleet that renews early, in small cohorts, with bounded retry and external proof may gain security without material availability risk. A fleet that renews in one batch, trusts order success and has no owner for stragglers may convert a scheduled control into synchronized failure.

Public sources cannot establish which description fits a particular subscriber. They reveal no private endpoint inventory, error budget, client version, account custody or incident record. Nor do they prove that shorter certificates eliminate revocation or key compromise. The defensible conclusion is narrower: the schedule makes replacement evidence more valuable and stale assumptions less affordable.

Sources