# Let's Encrypt to cut certificate lifetimes from 90 to 45 days

> ISRG plan: 45-day certs on the tlsserver profile from May 2026, a 64-day default from Feb 2027, then 45 days with 7-hour authz reuse from Feb 2028.

Source: https://ssl.sh/news/lets-encrypt-45-day-certificates/
Last updated: 2026-11-10

Let's Encrypt certificates will shrink from 90 days to 45 days in stages through February 2028, according to a plan ISRG announced on 2 December 2025. That keeps Let's Encrypt inside the CA/Browser Forum's 47-day ceiling for March 2029. Authorization reuse, the time one domain validation can back new certificates, will drop to 7 hours.

## What happened

The plan changes Let's Encrypt's [ACME profiles](https://ssl.sh/glossary/acme-profile/) in three steps:

1. **2026-05-13**: the opt-in tlsserver profile issues 45-day certificates.
2. **2027-02-10 (upcoming)**: the default classic profile moves to 64-day certificates, with authorizations reusable for 10 days.
3. **2028-02-16 (upcoming)**: the classic profile moves to 45-day certificates, with authorizations reusable for only 7 hours.

The first step affects only subscribers who explicitly request the tlsserver profile. The classic profile, which every ACME client receives unless it asks for something else, is not scheduled to change until February 2027. The 45-day figure sits just below the 47-day maximum that [Ballot SC-081](https://ssl.sh/news/ballot-sc-081-shorter-certificate-lifetimes/) sets for 2029, while the 7-hour authorization reuse is far stricter than the 10 days that ballot allows.

## Who is affected

Every Let's Encrypt user is affected eventually. Setups that hard-code a 90-day lifetime break first:

- cron jobs or scripts that renew on a fixed calendar, such as every 60 days;
- monitoring that alerts at a fixed number of remaining days, which can fire constantly once a fresh certificate lasts only 45 days;
- workflows that validate a domain once and then issue several certificates over the following days, relying on cached authorizations;
- manual [DNS-01](https://ssl.sh/glossary/dns-01/) validation, where someone adds a TXT record by hand.

Hosting panels and managed platforms that renew through ACME on their own schedule should follow the change automatically, but confirm how they decide when to renew.

## What you should do

Base renewal timing on the certificate's actual lifetime, not on a calendar.

- Let your ACME client decide when to renew. Clients that support [ARI](https://ssl.sh/glossary/ari/), ACME Renewal Information (RFC 9773), let the CA suggest a renewal window, which also helps during mass revocation events.
- Automate DNS-01 through your DNS provider's API if you need wildcard certificates.
- Try the shorter lifetime early by requesting the tlsserver profile on a staging or low-risk host.
- Set alert thresholds relative to the lifetime, for example when less than a third of it remains.

Check the lifetime of what you actually serve:

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -startdate -enddate
```

Confirm renewal works end to end:

```bash
sudo certbot renew --dry-run
```

The [47-day certificates guide](https://ssl.sh/learn/47-day-certificates/) and the [renewal automation guide](https://ssl.sh/learn/automate-certificate-renewal/) cover client set-up; the [Let's Encrypt timeline](https://ssl.sh/timeline/lets-encrypt/) lists every dated change.