HTTPS used to mean expensive, fiddly certificates. Let's Encrypt changed that: it's free, and issuance through renewal can be fully automated. Here's how it works, from a defender's point of view.
How it works: proving domain control, automatically (ACME)
Traditional certificates meant applying, submitting identity paperwork, and waiting — all by hand. Let's Encrypt replaces that with ACME (Automatic Certificate Management Environment), a protocol that turns the whole exchange into machine-to-machine steps.
The key point: it only verifies control of the domain (Domain Validation, DV). It doesn't vet a company's legal existence, which is why the process is light enough to fully automate. The encryption itself is no weaker than a paid certificate.
The 90-day lifetime exists because renewal is meant to be automatic
Let's Encrypt certificates are valid for 90 days. The short window is deliberate.
Limit the damage from a leaked key
If a server's private key ever leaks, a short-lived certificate shortens the period it can be abused — and even if revocation lags, it expires on its own.
Make automated renewal the default
90 days is impractical to renew by hand, so operators have to automate — which pushed the whole industry toward "certificates are something you rotate automatically." In practice, renewal tools start trying ~30 days before expiry.
So the real job is monitoring
Automated renewal can stop without anyone noticing: a broken cron, changed permissions, a domain check that no longer passes. If you don't notice, 90 days later it expires. The defensive habit is to monitor renewal success and the days remaining.
Our take: we run it this way ourselves (automatic TLS)
This site runs on the Caddy web server, which issues and renews Let's Encrypt certificates automatically just by pointing a domain at it (there's barely any certificate config). "Not having to think about certificates" is the goal: the fewer places a human touches by hand, the fewer expiry incidents from a forgotten swap.
If instead you run certbot on a cron, the safe move is to monitor whether that cron is actually still running, not just trust that it is.
Lifetimes are getting shorter (schedule as of October 2026)
90 days is the standard today, but Let's Encrypt has announced it will shorten lifetimes in steps. The CA/Browser Forum, the industry body of browser makers and certificate authorities, has also decided to cut the maximum lifetime of browser-trusted certificates in stages starting March 2026, reaching 47 days in March 2029.
| When | What changes |
|---|---|
| As of October 2026 | 90-day lifetime |
| From May 13, 2026 | Opt-in tlsserver profile offers 45-day certificates |
| From February 10, 2027 | The default (classic profile) moves to 64 days; reuse of domain validation drops to 10 days |
| From February 16, 2028 | The default moves to 45 days; reuse of domain validation drops to 7 hours |
A shortlived profile with roughly six-day (160-hour) certificates has also been generally available since January 2026. IP address certificates are only issued as these short-lived certificates.
The practical point: don't hardcode a renewal interval such as "every 60 days." Let's Encrypt recommends a client that supports ARI (ACME Renewal Information), where the CA tells the client when to renew; without ARI, renew once two thirds of the lifetime has passed. A cron job with a fixed number of days will start causing expiries once lifetimes shrink.
What ended in 2025: OCSP and expiry emails
Let's Encrypt stopped two things in 2025. Watch out if you follow older articles or configs.
- OCSP (checking each time whether a certificate has been revoked): OCSP URLs were removed from certificates on May 7, 2025, and the responders were shut down on August 6. Revocation checking now relies on CRLs (lists of revoked certificates). One reason was privacy: with OCSP, the CA could learn which IP address was visiting which site.
- Expiry notification emails: these stopped on June 4, 2025. You used to get an email as expiry approached; now you don't. You need your own expiry monitoring.
The #1 incident: a stalled renewal, then expiry
The most common HTTPS problem isn't an attack — it's an expired certificate. On expiry the browser throws a full-page warning and visitors almost always leave. The cause is nearly always "renewal automation had broken and nobody noticed."
That's exactly why you should have a way to periodically look at your own certificate's expiry. This site's site security audit checks the TLS certificate (days remaining, expiry, outdated protocols) on a site you've verified you own, alongside the other checks. Automate the renewal, then verify from the outside that the automation is still running. Together, these two habits prevent expiry incidents almost entirely.
The domain validation methods (challenges) compared
ACME offers three ways to prove you control a domain. Pick the one that fits your setup.
| Method | What you place | Wildcard certificates | Good fit |
|---|---|---|---|
| HTTP-01 | A file at a fixed path on your web server | No | An ordinary web server reachable on port 80 |
| DNS-01 | A TXT record in DNS | Yes | You need *.example.com, or the server isn't publicly reachable |
| TLS-ALPN-01 | A response on a TLS connection to port 443 | No | Large hosting providers and reverse proxies |
Automating DNS-01 means keeping a DNS API key on the server. If that key leaks, someone can change your domain's records, so choose a DNS provider that lets you limit the key to TXT records and keep the key in as few places as possible.
How to check your own site
Check the issuer and expiry in the browser
Check that renewal really runs
certbot certificates shows expiry dates and certbot renew --dry-run tests renewal. On systemd hosts, check that a certbot timer appears in systemctl list-timers. Caddy records certificate issuance and renewal in its logs.Look for certificates you didn't request
Limit which CAs can issue for you
Monitor the days remaining from outside
Example: the 2021 root certificate expiry
Certificates are verified through a chain that ends at a trusted root certificate. Let's Encrypt certificates were originally trusted through another CA's root (DST Root CA X3), and that root expired on September 30, 2021.
From that day, older devices and software that did not trust Let's Encrypt's own root (ISRG Root X1) started showing certificate warnings on sites using Let's Encrypt (older Android devices kept working thanks to a special arrangement). The site's certificate was renewed correctly, yet users with old devices could no longer connect.
If you run APIs or systems that old devices connect to, follow Let's Encrypt's announcements and prepare for intermediate and root changes. Let's Encrypt advises against hardcoding intermediate certificates in config; use the chain your ACME client receives.
Read next
- Learn from an incident: Heartbleed (a TLS/OpenSSL flaw that put the private keys of many servers at risk)
- Check your own site: site security audit (TLS cert, headers, exposed files in one report)
- Basics: the security baseline checklist for indie developers
Sources (primary)
- Let's Encrypt official blog (December 2, 2025, plan to shorten lifetimes to 45 days) — letsencrypt.org (dates for 64 and 45 days, validation reuse periods, ARI recommendation)
- Let's Encrypt official blog (January 15, 2026, general availability of six-day and IP address certificates) — letsencrypt.org
- Let's Encrypt official blog (December 5, 2024, ending OCSP) — letsencrypt.org (dates for removing OCSP URLs and shutting down responders)
- Let's Encrypt official blog (January 22, 2025, ending expiry notification emails) — letsencrypt.org
- Let's Encrypt, "Challenge Types" — letsencrypt.org
- Let's Encrypt, "Integration Guide" — letsencrypt.org (renewal timing, not hardcoding intermediates)
- Let's Encrypt, "DST Root CA X3 Expiration (September 2021)" — letsencrypt.org
- CA/Browser Forum, "Ballot SC081v3" (passed April 11, 2025) — cabforum.org (maximum lifetime of public certificates reaching 47 days in March 2029)