Why Let's Encrypt certs are only 90 days

Let's Encrypt public DV certificates are capped near ninety days by policy—plan automation and monitoring, not one-year manual renewals.

When this happens

Finance asks why certificates expire quarterly when a vendor sold them a five-year warranty story. Audit findings ask for annual crypto reviews while operations already renew twelve times per year automatically.

Staging certs on ninety-day cycles break CI because someone expected annual renewals. Vendor RFPs still request three-year DV despite operations already automated for ninety days.

First response

Why Let's Encrypt certificates last 90 days and how to run reliable short-lived DV renewal with automation.

Searches for let's encrypt 90 day certificate usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For Why Let's Encrypt certs are only 90 days, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

Leadership questions about ninety-day certificates usually surface during budgeting, not during an outage. The answer is policy: short-lived certs shrink compromise windows and force automation. Planning renewals every sixty days with monitoring beats annual manual purchases that silently fail on challenge weekends. Procurement should align contract language with operational reality: frequent renewals are cheaper than outage PR when a three-year DV cert expires untouched. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius.

See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.

Why renewal failed

Short lifetime forces operational discipline and limits key compromise blast radius. Browser trust programs and CT logs assume frequent rotation; long commercial certs do not exempt you from reloading services when they eventually renew. Education and monitoring together replace mythical one-year DV lifetimes in operations culture.

Certbot defaults renew around thirty days remaining; you should still monitor earlier. Disaster recovery sites must run the same short cadence; cold standbys forgotten for a year expire dramatically on the same calendar week. Disaster recovery sites need identical automation cadence, not slower manual calendars.

Commercial one-year certs do not remove reload requirements—they only delay the same failure modes. Align internal crypto policy docs with CA/Browser Forum baseline so audits do not conflict with LE cadence.

Let's Encrypt caps public DV lifetime at ninety days by baseline requirements in the Web PKI. Certbot renews at roughly thirty days remaining by default. Treating short life as a bug leads teams to buy one-year certs without fixing reload discipline—the operational risk returns on day 366. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs.

Ninety-day certs are not lengthened by paying Let's Encrypt. They are not optional on the default public ACME API. Buying a one-year cert does not remove the need to reload web servers when that year ends.

Common causes

These patterns drive most let's encrypt 90 day certificate tickets. They explain why automation logs look green while browsers or APIs still break.

Runbooks assumed annual renewals and cron ran once a year. Finance bought multi-year OV while dev still used LE staging on production names.

Automation never deployed because operators believed quarterly manual work was cheaper than hooks.

Misread CA marketing about ninety-day trials versus production subscriptions.

Diagnose

Demonstrate lifetime from a live cert and from certbot certificates output.

Use certbot certificates to list real expiry dates rather than guessing from procurement contracts. If anxiety is operational, demo a successful dry-run renew and live openssl check in one change window. Pull one CT log entry for a production host to show ninety-day cert lifetimes in the public transparency ecosystem.

Fix step-by-step

Follow this sequence for why let's encrypt certs are only 90 days. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Show openssl notAfter minus notBefore on a production LE cert.
2. Document renewal cadence in runbooks and CMDB.
3. Enable certbot timer or equivalent orchestration.
4. Set alerts at fifty, thirty, and fourteen days.
5. Use staging ACME for integration tests.
6. Reserve commercial certs only where policy demands OV/EV.
7. Train teams that frequent renew is normal when automated.
8. Review incident history for manual renew misses.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate.

How to read the output

Show stakeholders notAfter minus notBefore from openssl output on a live LE cert—roughly ninety days. Compare to a legacy cert if still on one hostname for contrast.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Document renewal cadence in the CMDB and tie alerts to fifty-day and thirty-day thresholds.

Deploy certbot timer or cert-manager everywhere public DV suffices; reserve commercial certs for names needing EV/OV.

Train teams that frequent renewals are normal when automation and external monitoring cover the fleet. Publish an internal FAQ linking BR milestones to your monitoring thresholds so auditors understand ninety-day design.

What to automate

Automate dry-run renew monthly plus external notAfter checks. Automate reminders at well-under ninety-day boundaries aligned with your renewBefore settings.

ssldays aligns monitoring cadence to short-lived certs with escalating reminders. ssldays gives executives objective expiry visibility alongside internal policy training.