Certificate Lifetimes Just Got Cut to 825 Days, and the Trend Points Shorter

A change took effect on March 1st that will eventually touch every website with a padlock: newly issued TLS certificates are now capped at 825 days, roughly 27 months, down from the previous maximum of 39 months. No browser warning announced it and your vendor probably didn't email you, but the next time you renew, the three-year option won't be there.

On its face this is bookkeeping. In practice it's a clear signal of direction: certificate lifetimes have been shrinking for years, the pressure to shrink them further keeps building, and every cut makes "we'll remember to renew it" a worse strategy. Here's what changed, why, and what it means for how you run renewals.

What changed on March 1st

The cap comes from the CA/Browser Forum, the body of certificate authorities and browser vendors that sets the baseline rules every publicly trusted CA must follow. The ballot passed last year, and since March 1, 2018, no publicly trusted CA may issue a certificate valid for more than 825 days.

Details worth knowing:

• Existing certificates are unaffected. A three-year certificate issued in February 2018 stays valid until it expires. The cap applies to new issuance only.
• Reuse of validation data is also limited to 825 days. CAs must re-verify your control of a domain at least that often.
• It continues a steady trend. Five-year certificates went away in 2015 when the cap dropped to 39 months. Now it's 27. A proposal to cut lifetimes to about 13 months came up at the Forum last year. It failed, but the browsers clearly want shorter lifetimes, and few people expect 825 days to last long.

Why the industry keeps shortening lifetimes

Shorter lifetimes look like pure inconvenience: more renewals, more chances to fumble one. The browsers push for them anyway, for reasons that are hard to argue with:

• Revocation doesn't work well. In theory a compromised certificate gets revoked and browsers reject it. In practice revocation checking (CRLs, OCSP) is unreliable enough that browsers often soft-fail: if the check doesn't answer, the certificate is accepted. The revocation mechanism that works reliably at internet scale is expiry, so shorter lifetimes shrink the window in which a stolen key is useful.
• Mis-issuance cleanup takes years. When a CA is caught issuing certificates improperly, the bad certificates stay valid until they expire. The industry is living through this now: browsers are distrusting Symantec-issued certificates in stages through 2018, a process made much harder by the number of long-lived certificates still in use.
• Agility. The ecosystem regularly needs to move: deprecating SHA-1, migrating to stronger keys, rolling out new validation requirements. Every improvement spreads only as fast as the oldest surviving certificates age out.

Each of these arguments gets stronger at shorter lifetimes, which is why the trend only goes one way.

Audit what you have

Most organizations find they have more certificates than they thought: the www domain, the API, a staging box someone secured properly and then forgot, the mail server, the load balancer with a certificate baked into its config. Start with an inventory. For any host you can reach, checking the expiry date takes one command:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -enddate

Record each certificate's expiry, issuer and where it's deployed (renewing a certificate and forgetting to install it on the second load balancer is a classic), and you have the basis for a real renewal process.

Calendar reminders don't scale

The traditional renewal process is a calendar reminder in one person's inbox. That was fragile at three-year intervals, and it gets worse as lifetimes shrink. More certificates renewing more often means more renewal events per year, and each one is a chance for the reminder to land during a vacation, go to a departed employee's mailbox or get snoozed indefinitely. Expired certificates are a common and embarrassing cause of outages, and every one came with months of theoretical warning.

The sustainable answer has two independent halves:

• Automate renewal. This is becoming the norm. Let's Encrypt issues free 90-day certificates renewed entirely by software over the ACME protocol, and the 90 days are deliberate: short enough that automation is effectively required. Commercial CAs are building their own automation APIs. If a person currently renews your certificates by hand, fix that this quarter.
• Monitor expiry independently. Automation fails quietly: the cron job that runs the renewal client stops, a DNS change breaks domain validation, the renewed certificate never gets deployed to one of the servers. An external monitor that connects to your real endpoints, reads the certificate actually being served and alerts at 30, 14 and 7 days out catches all of these, because it checks the outcome rather than the process.

Shorter lifetimes reward the prepared

825 days won't be the last cut. Teams with automated renewal and independent expiry monitoring will barely notice future reductions. Teams relying on memory and calendar invites will feel each one as added outage risk.

CompleteStatus watches the certificates your servers actually serve, with expiry countdowns and alerts well before the deadline, plus checks for chain and configuration problems, alongside uptime and DNS monitoring in one dashboard. Create a free account and add your domains.