Let’s Encrypt Cuts Certificates to 45 Days by 2028

Let’s Encrypt announced on December 2 that it will cut SSL/TLS certificate validity from 90 days to 45 days by February 2028, with a phased rollout starting May 2026. The change affects over 500 million websites currently using Let’s Encrypt certificates and follows CA/Browser Forum requirements that all publicly-trusted Certificate Authorities must implement. Most aggressive change: the authorization reuse period drops from 30 days to just 7 hours, forcing near-instant domain validation for renewals.

This isn’t optional. Every developer using Let’s Encrypt needs to verify their automation handles shorter renewal cycles, or risk site outages starting in 2026.

The Timeline: 18 Months to Prepare

Let’s Encrypt is implementing a three-phase rollout. In May 2026, the “tlsserver” ACME profile will offer opt-in 45-day certificates for early adopters to test their automation. February 2027 brings the first mandatory change: the default “classic” profile shifts to 64-day certificates with a 10-day authorization reuse period. The final drop happens February 2028, when all certificates move to 45-day validity with just 7 hours of authorization reuse.

That 18-month window isn’t generous. It’s the minimum time to test, fix broken automation, and upgrade ACME clients before the mandatory switch. Waiting until 2028 is gambling with uptime.

The 7-Hour Authorization Window Breaks Multi-Cert Workflows

The most disruptive change isn’t the 45-day certificate lifetime—it’s the authorization reuse period collapsing from 30 days to 7 hours. Currently, you can validate domain control once and reuse that authorization for 30 days to issue multiple certificates. By 2028, you get a 7-hour window.

Here’s what breaks: validate your domain on Monday, issue a cert for server A, issue another cert for server B on Wednesday, maybe a third cert next week—all using the same authorization. In 2028, you validate once and have 7 hours to issue ALL certificates, or you re-validate from scratch. Workflows that lazily batch certificate requests over days or weeks will fail hard.

Let’s Encrypt hasn’t justified why 7 hours is the magic number versus 24 hours or even 12 hours. This feels unnecessarily aggressive.

Manual Renewals Are Dead

With 45-day expiration, manual certificate renewal becomes impractical. That’s 8 renewals per year compared to the current 4. Let’s Encrypt explicitly states: “We have long advised against manual certificate renewal, as the process is too error-prone and would now have to be performed twice as often.”

Real-world scenario: you’re a hobbyist developer who gets an email reminder every 90 days, SSHs to your server, runs certbot renew manually, done. With 45-day certificates, that becomes every 6 weeks. Miss one reminder because you’re on vacation, busy with a sprint, or your email filter caught it—site goes down with an HTTPS error. Community reaction from DEV.to nails it: “If your automation isn’t solid, your life is about to get harder.”

This is the forcing function. Let’s Encrypt is using shorter lifetimes to push the entire industry toward proper automation. If you’re still doing manual renewals in 2025, you have 18 months to automate or switch to managed hosting.

ACME Renewal Information Is the Fix

ACME Renewal Information (ARI), now published as RFC 9773, solves the timing problem. ARI lets Let’s Encrypt signal optimal renewal timing to ACME clients—normally around 60 days for a 90-day cert, but earlier if revocation is needed. Crucially, renewals using ARI are exempt from rate limits, so high-volume users won’t hit API limits during renewal spikes.

Certbot 4.1.0 and later versions support ARI automatically with no configuration changes needed. If you’re running an older ACME client, upgrading is the single most important preparation step. Check your client’s documentation for ARI support—if it doesn’t have it, consider switching to one that does.

Is 45 Days Actually Better Security?

Let’s Encrypt justifies the change as “limiting the scope of compromise and making certificate revocation technologies more efficient.” The security argument: if a private key is compromised, 45-day validity means only 45 days of exposure versus 90. Faster certificate rotation reduces breach impact.

The community isn’t entirely convinced. Critics note the change “doesn’t appear to be justified by anything quantitative, just theoretical attacks.” If 45 days improves security, why not 30 days? Why not 7? Where’s the data showing 90 days is insufficient? One pragmatic observer cuts through: “The idea here was exactly to create annoyance until everyone learns to fully automate certificate rotation.” It’s less about security, more about forcing industry maturity.

The 45-day lifetime makes sense as a forcing function for automation. The 7-hour authorization reuse window feels like security theater approaching the threshold of actual annoyance.

What to Do Now

Test early. When Let’s Encrypt enables opt-in 45-day certificates in May 2026, use them to verify your automation works. Upgrade your ACME client to Certbot 4.1.0 or equivalent with ARI support. Check your renewal logic—hardcoded 60-day schedules will fail with 45-day certificates. Automate or plan to fail, because manual renewals are officially dead. Monitor your renewals closely, since 45-day windows leave less margin for error when renewals fail.

This change is mandatory. The CA/Browser Forum requires all public CAs to implement similar reductions by 2028-2029. DigiCert, GlobalSign, and Sectigo are moving to 47-day maximums by March 2029. There’s no opting out of shorter certificate lifetimes. The only choice is whether you’re ready.