Certificate validity-period brevity

TL;DR: Every TLS certificate has a fixed lifetime baked into it at issuance — notAfter − notBefore in days. Counterintuitively, shorter is stronger. A 90-day cert proves you have working renewal automation, contains the damage if your private key leaks, and sidesteps the long-broken revocation-check path entirely. SSL Labs grades for “is it about to expire?” We grade for “how long was it ever valid for?” — a much better signal of modern operational hygiene.

What is it?

Every TLS certificate carries two timestamps signed by the issuing CA: notBefore (when it starts being valid) and notAfter (when it stops). The total validity period is just the difference between those two — measured in days.

Historically that number has shrunk dramatically:

Pre-2015: 3-year and even 5-year certs were routine. Buy once, forget for half a decade.
2018: CA/Browser Forum cap dropped to 825 days (about 27 months).
2020: Cap dropped again to 398 days (about 13 months) after Apple announced Safari would stop trusting longer-lived certs.
2025–2027: Apple has proposed a 47-day maximum to the CA/B Forum, with industry support from Google. Ratification is expected by 2027.

Running parallel to this trend has been ACME (Automatic Certificate Management Environment, RFC 8555) and Let’s Encrypt, which have issued 90-day certs by default since launch in 2015. Their whole pitch was: if renewal is automated, why does the cert need to last a year?

A decade later that’s the direction the entire web PKI is moving.

Why does it matter?

The intuition most people start with is “longer = less work, more stable.” It’s exactly backwards once you account for second-order effects.

Forces automation. If you can’t renew via cron, you can’t run a 90-day cert — you’ll outage every quarter. Anyone successfully running ≤90-day certs has working renewal automation, which means their rotation story for every other secret-rotating system is probably reliable too. This is the deepest benefit. Short certs turn cert renewal from a once-a-year manual fire-drill into a boring background process.

Smaller blast radius. If your private key leaks — backups stolen, LB misconfig leaving it world-readable, ex-employee with copies — the attacker can impersonate your site for at most the cert’s remaining lifetime, regardless of whether your revocation path works. A compromised 90-day cert burns out in three months. A compromised 3-year cert is a problem until 2029.

Revocation actually works. Browser-side revocation has been broken in practice for years. CRLs (Certificate Revocation Lists) got too big to ship. OCSP requires a network round-trip and soft-fails when unreachable, which means a network attacker can suppress revocation checks and the browser shrugs and connects anyway. Short certs sidestep the whole mess: the cert just expires before revocation needs to bite. Expiry is the one revocation mechanism that always works.

Real-world analogy

Long-lived certs are like physical office keys you cut in 2015 and still use. Convenient — you’ve never had to swing by the locksmith. But if a copy ever gets made, that copy works for years. You won’t even know it’s out there.

Short-lived certs are like conference badges that expire in 24 hours. Slightly more hassle: you have to re-issue them every day. But if one walks out the door, it’s a paperweight by tomorrow morning. The whole class of “stolen credential, used months later” attacks just doesn’t apply.

The 90-day cert is the conference badge. The 3-year cert is the office key.

A note on what SSL Labs measures vs. us

SSL Labs (and most legacy cert checkers) grade for “days remaining until expiry” — they’re warning you about an imminent outage. If your cert expires in 7 days, that’s an SSL Labs B; in 2 days, that’s a C. Useful! But it’s an operational alert, not a hygiene grade.

We grade for total issued lifetime — the gap between notBefore and notAfter baked into the cert at issuance. A cert that was issued for 90 days and has 5 days remaining is still excellent hygiene (the renewal cron will run any minute now). A cert that was issued for 800 days and has 700 days remaining is poor hygiene even though it’s nowhere near expiring.

Different question, different answer. A site can score a clean A on SSL Labs and still fail WEBQ-95 — that’s not a contradiction, it’s two different signals on the same scorecard.

How WQI measures this

We grade this as factor WEBQ-95 in the Security category. The computation is simple: parse the leaf cert’s notBefore and notAfter from ASN.1, subtract, and convert to days.

Lifetime	Result
≤ 90 days	Pass (100) — ACME-class hygiene
≤ 200 days	Warn (60) — typical 6-month cert
≤ 397 days	Warn (30) — CA/B Forum hard maximum
> 397 days	Fail (0) — over the maximum, shouldn’t exist

That last bucket is rare on the public web — publicly-trusted CAs haven’t been allowed to issue >398-day certs since 2020 — but private CAs and old long-lived certs that pre-date the cap still turn up.

What good looks like

ACME-class hygiene: ≤90-day certs with a daily renewal cron, on a mainstream CA with strong issuer reputation. The cert renews itself in the background. You haven’t thought about it in months. That’s the destination.

If your cert lifetime is over 200 days, you’re optimizing for the wrong thing — usually “minimize how often I deal with cert operations” instead of “make cert operations a non-event by automating them.” The fix isn’t a longer cert; it’s better plumbing.

How to fix it

Switch to an ACME-based issuer. They are all free and all default to 90-day certs with automated renewal:

Let’s Encrypt — the original. Default 90-day, broadest tooling ecosystem (certbot, acme.sh, lego, Caddy’s built-in client, etc.). The safe default for most deployments.
ZeroSSL — free 90-day via ACME. Useful as a Let’s Encrypt alternative or fallback issuer.
Buypass Go SSL — free 180-day via ACME (recently dropping toward 90). Norwegian CA, useful for geographic diversity.
Google Trust Services ACME — free for Google Cloud users, 90-day default. Useful if you’re already on GCP and want the cert pipeline inside the same trust boundary.

For larger deployments, run a daily renewal cron with whatever ACME client you’ve picked. Most clients are no-ops if the cert isn’t near expiry, so the daily run costs nothing on the days nothing needs to happen — but you’re protected against single missed renewals because the next day’s run picks up the slack.

The 47-day cap that Apple is pushing (likely ratified by 2027) means your tooling should already handle weekly renewal cleanly today. The good news: if your daily cron works for 90-day certs, it’ll also work for 47-day certs. The cadence changes; the architecture doesn’t.

Common pitfalls

Multi-year purchased certs from paid CAs. If you’re on a 2-year DigiCert or Sectigo cert, that was bought before the 2020 cap and is grandfathered. You can downgrade to a 1-year and ideally migrate to ACME at the same time. Every paid CA now has an ACME endpoint (or a partner who does).
Enterprise / internal CAs that issue long-validity certs. Common in audited environments where issuance requires manual review. Push back on this — the audit trail benefit is gone the moment the private key gets used in production. Short-lived, audit-logged automated issuance is strictly better.
Load balancers without ACME integration. Older F5 / Citrix / hardware LB setups historically had no ACME story; ops just uploaded a 1-year PEM by hand. Modern firmware almost all supports ACME (or sidecar tools like Caddy as TLS terminator) do the rotation upstream. If your LB still doesn’t, that’s a procurement / upgrade conversation worth having.
DNS-01 challenges that break. ACME’s DNS-01 challenge needs write access to your DNS provider’s API. If the API key rotates or the zone gets moved, renewal silently fails until the cert actually expires. Monitor renewal success, not just cert expiry.