---
title: "Let's Encrypt Is Cutting Certificate Lifetimes to 64 Days: What It Means and How to Prepare"
description: "Let’s Encrypt cuts default certificate lifetimes to 64 days on February 10, 2027. Learn what changes, why it matters, and how to prepare your team."
url: "https://www.gowrishankar.me/blog/let-s-encrypt-is-cutting-certificate-lifetimes-to-64-days-what-it-means-and-how-to-prepare"
author: "Gowri Shankar Balasubramaniam"
published: 2026-10-09T06:52:38.629Z
category: "Web Security"
tags: ["ACME","Automation","CA/Browser Forum","Certificate Lifecycle Management","Compliance","DevSecOps","Let’s Encrypt","PKI","SSL Certificates","TLS"]
---

# Let's Encrypt Is Cutting Certificate Lifetimes to 64 Days: What It Means and How to Prepare

> Starting February 10, 2027, Let’s Encrypt will issue 64-day certificates by default, with 45 days to follow in 2028. Most automated setups will be fine, but hardcoded renewal schedules, manual processes, and forgotten appliances will not. This post explains the change and how to prepare.

## Key takeaways

- The date is February 10, 2027. From then on, Let’s Encrypt’s default profile will issue certificates that are valid for 64 days instead of 90. Existing certificates are not affected; the change takes effect at your first renewal after that date.
- This is the first step, not the last. Lifetimes drop again to 45 days on February 16, 2028. Across the industry, CA/Browser Forum Ballot SC-081v3 caps every public TLS certificate at 47 days from March 2029.
- Domain validation will happen far more often. The authorization reuse period shrinks from 30 days to 10 days in 2027, and to 7 hours in 2028. Fragile HTTP-01 or DNS-01 setups will fail more frequently.
- Most automated setups will keep working. Mature ACME clients renew based on how much lifetime remains on the current certificate. The setups at risk are hardcoded renewal intervals, manual renewals, and certificates copied to appliances, CDNs, or keystores.
- Prepare now with a few concrete steps. Inventory your certificates, remove any hardcoded “90-day” assumptions, enable ACME Renewal Information (ARI), and test against 45-day certificates using the opt-in tlsserver profile.
- Monitor what your users actually see. Alert on the expiry date of the certificate your server is serving, not only on whether the renewal job ran. A silent renewal failure is the most common cause of certificate outages.

On February 10, 2027, every new certificate from Let's Encrypt's default profile will be valid for 64 days instead of 90. If your renewals are fully automated, you will probably never notice. If any part of your certificate lifecycle still depends on a person, a calendar reminder, or a cron job someone wrote in 2019, this is your four-month warning.

I have spent enough time in incident bridges to know how certificate outages usually happen. It is rarely a sophisticated failure. It is a renewal job that silently stopped working, an alert that went to a mailbox nobody reads, or an appliance that someone configured by hand and then forgot. Shorter lifetimes do not create those weaknesses. They simply give them less time to stay hidden.

This post walks through what is changing, why the industry is doing it, who is most likely to be affected, and a practical checklist to get ready before February.

## What exactly is changing

Let's Encrypt is cutting its default certificate lifetime from 90 days to 64 days in February 2027, then to 45 days in February 2028. The rollout uses ACME profiles, so you can opt in early, but the default `classic` profile changes for everyone on fixed dates ([Let's Encrypt announcement](<https://isrg.org/post/from-90-to-45/>)).

| Date | Profile | Certificate lifetime | Authorization reuse |
| --- | --- | --- | --- |
| Today (until Feb 10, 2027) | classic (default) | 90 days | 30 days |
| May 13, 2026 (already live) | tlsserver (opt-in) | 45 days | — |
| February 10, 2027 | classic (default) | 64 days | 10 days |
| February 16, 2028 | classic (default) | 45 days | 7 hours |

Two details are easy to miss. First, the dates apply to newly issued certificates, so you will see the shorter lifetime at your first renewal after each date, not on the day itself. Second, the authorization reuse period is shrinking too. That is the window after you prove domain control during which Let's Encrypt will issue again without re-validating. Dropping it from 30 days to 10 means your validation path (HTTP-01, DNS-01 or TLS-ALPN-01) will be exercised far more often, and any fragility there will surface sooner.

Let's Encrypt also offers an opt-in `shortlived` profile with roughly six-day certificates, which is unaffected by these defaults. Changes reach the staging environment about a month before each production date, which gives you a useful test window.

## Why this is happening

Let's Encrypt is not acting alone; it is getting ahead of an industry-wide mandate. In April 2025 the CA/Browser Forum passed [Ballot SC-081v3](<https://cabforum.org/working-groups/server/baseline-requirements/requirements/>), proposed by Apple, with 25 certificate authorities in favour, none against, and Apple, Google, Microsoft and Mozilla all voting yes ([Encryption Consulting](<https://www.encryptionconsulting.com/tls-cert-validity/>)). It caps the maximum validity of publicly trusted TLS certificates on a fixed ladder:

| Effective date | Maximum certificate validity |
| --- | --- |
| March 15, 2026 (in effect) | 200 days |
| March 15, 2027 | 100 days |
| March 15, 2029 | 47 days |

Let's Encrypt's 90-day certificates already sat well under the first two ceilings. Its move to 64 and then 45 days is a deliberate choice to reach the end state early and in controlled steps, rather than scrambling in 2029.

The security reasoning is straightforward once you have dealt with a key compromise in practice:

- **A smaller blast radius.** If a private key leaks or a certificate is mis-issued, a shorter lifetime caps how long that credential can be abused, whether or not anyone notices.
- **Revocation is weak in the real world.** Browsers have long treated revocation checking inconsistently, and Let's Encrypt has already retired its OCSP service in favour of CRLs. Expiry is the one control that always works, so shortening it does the job revocation was supposed to do. Shorter lifetimes also keep CRLs smaller and more efficient.
- **Fresher validation.** The shrinking authorization reuse window means domain control is proven closer to issuance. That limits the risk of a certificate being issued to someone who controlled the domain weeks ago but no longer does.
- **Forcing automation.** The Forum has been explicit that driving automated certificate lifecycle management is a goal. Manual processes do not scale to monthly renewals, and that is intentional.

## Who will actually feel it

If you run Certbot, Caddy, Traefik, cert-manager or a similar mature ACME client with default settings, you are most likely fine. Those clients renew based on the remaining lifetime of the current certificate, so they adapt automatically. The pain will land on the edges of the estate, where automation is partial or assumed.

- **Hardcoded renewal intervals.** Let's Encrypt calls this out directly: renewing on a fixed 60-day interval will not be sufficient. A job that renews "every 60 days" works with 90-day certificates and fails with 64-day certificates after only a few cycles of drift. The same applies to any script that assumes 90 days anywhere in its logic.
- **Manual renewals.** Anyone still copying certificates onto load balancers, firewalls, VPN concentrators or vendor appliances by hand will need to do it roughly six times a year instead of four, and eight times a year from 2028.
- **Fragile validation paths.** With authorization reuse dropping to 10 days, DNS-01 setups that rely on a person updating a TXT record, or HTTP-01 setups that break whenever a WAF rule or redirect changes, will fail far more often.
- **Certificates copied to other places.** A renewed certificate on the web server does not help if a copy also lives in a CDN, a Kubernetes secret, a Java keystore or an internal monitoring probe that nobody updates.
- **Rate limits during incidents.** More frequent renewals mean more issuance traffic. A misconfigured client that retries aggressively can hit Let's Encrypt rate limits exactly when you need a certificate most.

From a governance point of view, this is also a useful test of maturity. If an organisation cannot say how many Let's Encrypt certificates it has, where they are deployed, and who owns them, the 64-day change will expose that gap.

## A practical checklist before February 2027

The goal is not to survive one date; it is to build a renewal process that does not care what the lifetime is. Work through these in order.

1. **Build an inventory.** List every Let's Encrypt certificate, where it is deployed, which client renews it, and who owns it. Certificate Transparency logs (for example crt.sh) are a fast way to find certificates issued for your domains that nobody remembers.
2. **Remove hardcoded assumptions.** Search scripts, cron entries and runbooks for "90", "60 days" and fixed renewal dates. Renewal should be triggered by remaining lifetime, ideally at about two-thirds of the way through, which is the behaviour Let's Encrypt recommends.
3. **Enable ACME Renewal Information (ARI).** ARI lets the CA tell your client when to renew, including early renewal during a mass-revocation event. Check your client's documentation, since enabling it differs between clients, and upgrade older client versions that do not support it.
4. **Test against the shorter lifetime now.** Opt a non-production or low-risk service into the `tlsserver` profile, which has issued 45-day certificates since May 2026. If your automation handles 45 days cleanly, 64 days is a non-event. Use the staging environment for dry runs (for Certbot, `certbot renew --dry-run`).
5. **Harden domain validation.** Move DNS-01 to an API-driven provider with tightly scoped credentials, and confirm HTTP-01 paths are excluded from WAF rules and redirects. Keep an eye on DNS-PERSIST-01, a new challenge type Let's Encrypt is standardising so the TXT record no longer changes on every renewal.
6. **Automate distribution, not just issuance.** Use deploy hooks or a secrets pipeline to push renewed certificates to every location that holds a copy, and reload services afterwards.
7. **Monitor from the outside.** Alert on what clients actually see, not just on whether the renewal job ran. Alert at 21 days remaining and escalate at 7. A simple external check looks like this:

```bash
# Exit status 1 (alert) if the served certificate expires within 21 days
openssl s_client -connect gowrishankar.me:443 -servername gowrishankar.me </dev/null \
2>/dev/null | openssl x509 -noout -enddate -checkend 1814400

# Sample response
notAfter=Dec 30 09:34:02 2026 GMT
Certificate will not expire
```

8. **Plan for appliances that cannot automate.** For devices without ACME support, either terminate TLS in front of them on something that can, or move them to a commercial certificate or private PKI where appropriate. Document the exception and its owner.

For teams working toward SOC 2 or PCI DSS, this work maps cleanly onto existing controls: asset inventory, change management, cryptographic key management, and monitoring of security-relevant failures. A well-documented certificate lifecycle process is good evidence for an auditor and a genuine reduction in outage risk.

## Summary

The move to 64 days is a small step on paper and a meaningful one in practice. It is the first time the default Let's Encrypt lifetime has changed in a decade, and it is the warm-up for 45 days in 2028 and the industry-wide 47-day ceiling in 2029.

I would treat February 2027 as a rehearsal. Fix the brittle scripts, find the forgotten appliances, and put real monitoring in place now, while the stakes are still modest. Teams that do this work once will find that certificate lifetimes stop being something they think about at all, and that is exactly the outcome the industry is aiming for.

## Questions and answers



### When will Let’s Encrypt certificates change to 64 days?

Let’s Encrypt will switch its default “classic” ACME profile to issuing 64-day certificates on February 10, 2027. The change applies only to newly issued certificates, so existing certificates keep their 90-day validity. Most users will see the shorter lifetime at their first renewal after that date.

### Why is Let’s Encrypt shortening certificate lifetimes?

Let’s Encrypt is aligning with CA/Browser Forum Ballot SC-081v3, which reduces the maximum validity of public TLS certificates to 47 days by March 2029. Shorter lifetimes limit how long a compromised or mis-issued certificate can be abused, make up for unreliable revocation checking, and push organisations toward automated certificate management.

### Do I need to change anything if I use Certbot or another ACME client?

Most automated setups need no changes, because mature ACME clients renew based on how much of the current certificate’s lifetime remains. You should still check for hardcoded renewal intervals, such as renewing every 60 days. Enable ACME Renewal Information (ARI) where your client supports it, and set up monitoring that alerts you when a renewal fails.

### What is the authorization reuse period, and how is it changing?

The authorization reuse period is how long Let’s Encrypt accepts a previous domain validation before it requires you to prove control again. It drops from 30 days to 10 days in February 2027, and to 7 hours in February 2028. As a result, your HTTP-01 or DNS-01 validation path will run, and could fail, far more often.

### What comes after 64 days for Let’s Encrypt certificates?

On February 16, 2028, Let’s Encrypt will reduce its default certificate lifetime again, to 45 days, with a 7-hour authorization reuse period. You can test 45-day certificates now through the opt-in “tlsserver” profile, which has been available since May 13, 2026. A 6-day “shortlived” profile is also available.

## Sources

- [Decreasing Certificate Lifetimes to 45 Days, Let's Encrypt / ISRG, December 2, 2025](<https://isrg.org/post/from-90-to-45/>)
- [Upcoming Changes to Let's Encrypt Certificates, Let's Encrypt Community](<https://community.letsencrypt.org/t/upcoming-changes-to-let-s-encrypt-certificates/243873>)
- [CA/Browser Forum Baseline Requirements](<https://cabforum.org/working-groups/server/baseline-requirements/requirements/>)
- [TLS certificate validity and SC-081v3, Encryption Consulting](<https://www.encryptionconsulting.com/tls-cert-validity/>)
- [DNS-PERSIST-01 draft, IETF](<https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dns-persist-01>)

---

Source: https://www.gowrishankar.me/blog/let-s-encrypt-is-cutting-certificate-lifetimes-to-64-days-what-it-means-and-how-to-prepare