Back to 47-Day Certificate Timeline
90-Day CertsAutomationACME

90-Day Certificates: Why They Exist and How to Stop Renewing Them by Hand

90-day certificates are now the long end of the curve. Why short lifetimes exist, what's replacing them (45- and 6-day certs, the 47-day rule), and how to automate.

8 min readJuly 2026Certificate Lifecycle Guide
90-Day Certificate Lifetime Guide — countdown timer showing certificate validity period

Quick Answer

A 90-day certificate is a TLS/SSL certificate whose validity period is capped at roughly three months instead of the year-plus that used to be normal. Let's Encrypt made 90 days famous — it has been their default since 2015 — and the whole industry is now moving shorter, not longer. Let's Encrypt is dropping its default to 45 days and already offers 6-day certificates; the CA/Browser Forum has locked in a schedule that takes the public-web maximum from 200 days today down to 47 days by 2029. If you're still renewing certificates by hand, 90 days is your warning shot: the only durable fix is automated issuance and renewal (ACME). Everything below is how to get there.

What a 90-day certificate actually is

Nothing about the certificate itself is special. It's an ordinary X.509 TLS certificate — same key, same chain, same validation — with a notBefore/notAfter window of about 90 days. Check any certificate's window with OpenSSL:

# From a file
openssl x509 -in cert.pem -noout -dates

# From a live host
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

You'll get notBefore= and notAfter= lines. Subtract them and you have the lifetime. A Let's Encrypt cert issued today reads ~90 days; a cert from the shortlived profile reads ~6 days.

Why do 90-day certificates exist?

Shorter lifetimes are a security decision, not an inconvenience for its own sake. Three reasons drive it:

Revocation barely works

When a key is compromised, CRLs and OCSP are slow, cached, or soft-failed by browsers. A short lifetime is revocation you can actually rely on — a bad certificate ages out in days, not months.

Less time for drift

Certificates outlive the facts they assert — domain ownership, company names, key hygiene. A 90-day cap keeps what's in the certificate close to what's true right now.

It forces automation

This is the real point. You cannot hand-renew a 90-day (let alone a 6-day) certificate at scale. Short lifetimes push operators onto ACME, which is where the ecosystem wants everyone anyway.

Let's Encrypt picked 90 days in 2015 precisely to make manual issuance impractical and automation the default path. Google's public 2023 push for 90-day maximums used the same logic.

90 days is now the long end of the curve

The important 2026 context: 90 days is no longer aggressive. It's the comfortable end. Here's where certificate lifetimes are actually headed.

Let's Encrypt (from its "From 90 to 45" announcement):

DateChange
Jan 15, 20266-day and IP-address certificates generally available (shortlived profile)
May 13, 2026tlsserver profile switches to 45-day certs (opt-in)
Feb 10, 2027Default classic profile moves to 64-day certs (10-day auth reuse)
Feb 16, 2028classic profile reaches its final 45-day certs (7-hour auth reuse)

CA/Browser Forum ballot SC-081v3 — the public-web maximum for every publicly trusted CA:

EffectiveMax validityCerts actually issued for
Mar 15, 2026 (in effect now)200 days199 days
Mar 15, 2027100 days99 days
Mar 15, 202947 days46 days

So the trajectory is unambiguous: 200 → 100 → 47 on the public web, with Let's Encrypt already pushing its own default to 45 and offering 6. Full breakdown of the industry-wide schedule is in our 47-Day Certificate Timeline guide.

How to live with 90-day (and shorter) certificates

The answer is always the same: automate issuance and renewal with ACME, then monitor. Pick the path that matches your stack.

Standalone servers — Certbot

Certbot renews anything within 30 days of expiry and installs a systemd timer or cron job on setup. Verify it actually works before you trust it:

certbot renew --dry-run

Certbot 4.0+ understands ACME profiles, so you can opt into short-lived certs directly:

certbot renew --preferred-profile shortlived

Reverse proxies that do it for you

Caddy issues and renews TLS certificates automatically with zero config — see our ACME Protocol guide for how the handshake works under the hood.

Kubernetes

cert-manager handles issuance and renewal as Custom Resources; it renews at two-thirds of the certificate's lifetime by default, which is exactly what you want as lifetimes compress.

Renew smarter, not just more often

As certs get shorter, renewal timing matters. ACME Renewal Information (ARI, RFC 9773) lets the CA tell your client the ideal renewal window — including "renew now" during a mass-revocation event — instead of every client guessing. If you're automating at scale, turn it on: ARI Readiness.

Always monitor expiry independently

Automation fails silently — a broken hook, an expired API token, a DNS change. Keep an external check that alerts on notAfter regardless of what your ACME client thinks it did.

The teams that get burned by shorter lifetimes aren't the ones who lack tools; they're the ones with one un-automated cert nobody remembered. That blind spot is exactly what our PKI Automation Gap guide is about.

Where this is heading next

Two signals from mid-2026 worth watching. First, short-lived certificates are becoming ordinary infrastructure, not an experiment — 6-day certs are GA, and Certbot, Caddy, and cert-manager all support them today. Second, the same crypto-agility push is arriving through post-quantum work: Microsoft's Trusted Root Program is piloting PQC requirements (ML-DSA), and AD CS added ML-DSA certificate support in 2026. The common thread is that certificates are becoming short-lived, automated, and swappable by design. A PKI built around 90-day manual renewals isn't ready for either shift.

Frequently Asked Questions

What is a 90-day certificate?

A standard TLS/SSL certificate with a validity window of about 90 days. It's technically identical to a longer cert — only the notAfter date is shorter.

Why is Let's Encrypt only 90 days?

To make automation the default and keep revocation-by-expiry fast. As of 2026 they're going further, moving the default to 45 days and offering a 6-day shortlived profile.

Are 90-day certificates going away?

Not going away — being undercut. 90 days remains widely issued, but the public-web maximum is dropping to 100 days in 2027 and 47 in 2029, and Let's Encrypt's own default is heading to 45.

Why 47 days for certificates?

It's the CA/Browser Forum's final SC-081v3 target (effective March 2029), reached in phases from 200 days. The reasoning is the same as 90 days, taken further: faster expiry, tighter data freshness, and mandatory automation. See the 47-Day Certificate Timeline.

Not sure your PKI can survive shorter lifetimes?

Run the 47-Day Readiness Audit Checklist and find the un-automated certs before they find you.

Run the 47-Day Readiness Audit