Let's Encrypt 45-Day Certificates: What Website Owners Need to Know

A Let's Encrypt certificate issued today still lasts 90 days. That will not be true for much longer. The CA/Browser Forum has already locked in a phased cut to a 47-day maximum by 2029, and Let's Encrypt is moving ahead of the rules: 45-day certificates are available right now, and the default profile drops to 64 days in February 2027. For most site owners this will be a non-event. For anyone renewing by hand, or running a control panel with a hard-coded renewal rule, it is a scheduled outage with a known date.

Facts in this article were verified against Let's Encrypt and CA/Browser Forum sources on 28 July 2026.

Two schedules are running at once

There are two separate timelines, and confusing them is the source of most of the bad advice circulating right now.

The first is the industry rule. In April 2025 the CA/Browser Forum passed Ballot SC-081v3 — 29 votes in favour, none against — which sets a phased reduction in both the maximum certificate lifetime and how long a certificate authority may reuse an old domain-control validation.

The second is Let's Encrypt's own schedule, published on 2 December 2025. It is deliberately more aggressive than the ballot requires.

The May 2026 step has already happened, though not smoothly: the accompanying migration to the new "Generation Y" intermediates slipped two weeks after Let's Encrypt found cross-certified subordinate CAs missing the serverAuth EKU, finishing on 28 May 2026.

Where things stand today

As of late July 2026, Let's Encrypt offers four ACME profiles — one of which has just been retired:

So if you have changed nothing, you are still on 90-day certificates. The date to put in your calendar is 10 February 2027, when the default becomes 64 days. Nothing renews retroactively: each certificate simply picks up the new lifetime the next time it is issued.

Why lifetimes are shrinking at all

The honest reason is that certificate revocation has never worked properly. When a private key leaks, the theoretical fix is to revoke the certificate — but browsers largely soft-fail when they cannot reach a revocation endpoint, and revocation lists propagate slowly. A stolen key can stay useful for the remainder of a 398-day certificate.

Short lifetimes make expiry itself the revocation mechanism: a compromised key on a 45-day certificate is worthless within six weeks, whether or not anyone noticed. The parallel cut to validation reuse does the same for domain ownership — if a domain changes hands or a DNS record is hijacked, the window in which a CA keeps trusting the old proof shrinks from months to days.

The tradeoff is blunt. This is a security gain paid for in operational reliability: certificates that renew four times a year become certificates that renew eight times a year, then seventeen. Any process with a human step in it fails at that cadence.

Automation is now the whole story

The mechanism that makes this manageable is ACME Renewal Information (ARI), standardised as RFC 9773. Instead of your ACME client guessing a renewal date from a number someone typed into a config file years ago, the CA publishes a recommended renewal window and the client follows it. Certbot and a growing list of other clients already support it.

ARI also lets a CA pull renewals forward during an incident — if a batch of certificates has to be replaced early, ARI-aware clients re-issue automatically instead of waking up to a mass revocation notice.

The practical instruction is short: use an ACME client that supports ARI, and stop configuring renewal thresholds by hand.

What actually breaks

Shorter lifetimes rarely break the ACME client itself. They break everything built around it.

• Fixed renewal thresholds. cPanel's AutoSSL renews 30 days before expiry — on a 45-day certificate that means re-issuing on day 15. It works, but it is wasteful, and any threshold longer than the certificate lifetime turns into a permanent renewal loop.
• Manual DNS-01 validation. Pasting a TXT record by hand survives while authorization reuse is 30 days. From February 2027 that drops to 10 days, and in 2028 to 7 hours. Let's Encrypt has a replacement in development — DNS-PERSIST-01, a static TXT record that persists across renewals — but it has not shipped yet.
• Certificates copied by hand to a second machine: load balancers, mail servers, Java keystores, firewall appliances. Seventeen renewals a year is seventeen chances to forget.
• Pinned certificates and hard-coded fingerprints in mobile apps or API clients. Pinning to a leaf certificate was already a bad idea; at 45 days it is unmaintainable.
• HSTS with a long max-age. If a certificate lapses on an HSTS site, visitors get a wall, not a warning they can click through. Worth re-reading our guide to security headers first.

Rate limits are not the problem

A common worry is that doubling renewal frequency will hit Let's Encrypt's rate limits. It will not. Let's Encrypt addressed this on 24 February 2026: renewals are exempt from the new-certificate limits, so nobody needs a limit increase because of the transition. Their worked example — 250 new certificates and 15,000 renewals a day — sits comfortably inside the defaults both before and after.

Checklist

Run this against every site and appliance you are responsible for:

1. Identify who issues the certificate — your host's control panel, an ACME client you installed, or a CDN in front of the origin. If you cannot answer in under a minute, fix that first.
2. Confirm the client supports ARI. If it does not, upgrade or replace it.
3. Remove hard-coded renewal thresholds wherever the client can work out the timing itself.
4. Test a forced renewal now, while you still have 90 days of slack.
5. Replace manual DNS-01 steps with an API-driven DNS provider, or move to HTTP-01.
6. Map every place a certificate is copied after issuance, and automate the copy.
7. Monitor renewal success, not expiry. An expiry alert at 14 days is a last resort; an alert on a failed renewal job is what saves you.
8. If your host is the issuer, ask directly: which ACME profile do you use, and what is your renewal window?

FAQ

Are Let's Encrypt certificates 45 days long right now?

Only if you have opted into the tlsserver profile. The default classic profile still issues 90-day certificates as of July 2026. The default becomes 64 days on 10 February 2027 and 45 days on 16 February 2028.

Do I have to do anything today?

If your certificates renew automatically through a maintained ACME client or your host's control panel, no. If any part of your renewal involves a person, yes — and the cheapest time to fix it is now.

Will shorter certificates cost more?

No. Let's Encrypt certificates remain free, and the ACME protocol does not charge per issuance. The cost is operational, not financial.

Does this affect paid certificates from commercial CAs?

Yes. SC-081v3 is a CA/Browser Forum baseline requirement, so it binds every publicly trusted CA. Commercial certificates are capped at 100 days from 15 March 2027 and 47 days from 15 March 2029.

What about the 6-day shortlived profile?

It exists for operators with fully reliable automation and, unusually, supports IP address identifiers. It is a good stress test: if your setup survives 6-day certificates, 45 days is trivial.

How do I check whether my hosting handles this properly?

Look for automatic issuance and renewal with no manual step, a wildcard option if you need subdomains, and support that can name the ACME client and profile they run. Practice differs widely — compare what is on offer in web hosting and, if you manage your own stack, VPS hosting.

What to do next

The change itself is not dramatic; the new dependency on automation is. If every certificate you own renews untouched, February 2027 passes unnoticed. If even one renewal depends on someone remembering, that is a fixed appointment with downtime.

Audit your certificate inventory this week rather than next February, and check that "automatic SSL" is genuinely automatic on the plans you use. Our WordPress hosting checklist covers where SSL sits among the other things a host should be handling for you.

Sources

• CA/Browser Forum — Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• Let's Encrypt — Decreasing Certificate Lifetimes to 45 Days
• Let's Encrypt — Shorter Certificate Lifetimes and Rate Limits
• Let's Encrypt — Certificate Profiles
• Let's Encrypt — Simplifying Certificate Renewals with ACME Renewal Information (ARI)