If you manage a website—whether it's a personal blog, an e-commerce store, or a corporate portal—you've probably heard the news. Let's Encrypt, the nonprofit certificate authority that revolutionized web security by making SSL/TLS certificates free and accessible, is about to shake things up again. They're moving to 45-day certificate lifetimes starting February 2028, a full year before the CA/Browser Forum's industry-wide mandate.
But here's what really matters: This isn't just a technical adjustment. It's a fundamental admission that our current approach to certificate security has been broken for years. The revocation system—the mechanism meant to quickly invalidate compromised certificates—simply doesn't work effectively in practice. Instead of fixing that broken infrastructure, the industry is taking a different path: making certificates expire faster so compromised ones become useless more quickly.
In this article, we'll explore what this change really means for you, why it's happening now, and most importantly, how you can prepare. We'll look at the automation challenges, security implications, and practical steps you need to take before 2028 arrives. Because while that might sound like distant future, the reality is that infrastructure changes take time—and the clock is already ticking.
The Broken Promise of Certificate Revocation
Let's start with the uncomfortable truth that's driving this entire shift. For years, we've operated under the assumption that if a certificate gets compromised—maybe a private key leaks, or a CA gets hacked—we can simply revoke it. The certificate authority would publish a revocation list, browsers would check it, and boom: the bad certificate stops working.
Except that's not how it works in practice. Not even close.
Revocation checking adds latency to every HTTPS connection. Browsers have to fetch and verify these lists, which slows things down. To compensate, most browsers implement what's called "soft-fail" revocation checking—if they can't reach the revocation server, they just let the connection proceed anyway. Attackers know this. They can simply block access to revocation servers, and suddenly that compromised certificate works just fine.
There's also the scale problem. Let's Encrypt issues over 3 million certificates every day. Maintaining real-time revocation status for that volume is practically impossible. The infrastructure would be massive, expensive, and still vulnerable to the same blocking attacks.
So what's the alternative? Make certificates expire faster. A lot faster. If a certificate only lasts 45 days instead of 90 (or the old standard of 398 days), then even if it gets compromised, it becomes useless relatively quickly. It's a pragmatic solution to a problem that's proven incredibly difficult to solve technically.
Why Let's Encrypt Is Moving First
You might be wondering: If the CA/Browser Forum mandate doesn't kick in until 2029, why is Let's Encrypt jumping the gun by a full year? The answer reveals a lot about their philosophy and operational model.
First, Let's Encrypt has always been about pushing the industry forward. They pioneered free certificates when everyone said it couldn't be done. They normalized automation when manual certificate management was the standard. Now they're leading the charge on shorter lifetimes because they believe it's the right thing for security.
But there's a practical reason too. Let's Encrypt's entire infrastructure is built around automation. Their ACME protocol was designed specifically for automated certificate issuance and renewal. While traditional CAs still have significant manual processes and enterprise customers who might resist change, Let's Encrypt's user base is already automated. Or at least, it should be.
"We're giving organizations runway to adapt," the announcement says. And that's true—February 2028 is still a couple years away. But the real message is subtler: If you're not automating your certificate management by now, you're already behind. The move to 45-day certificates just makes that reality impossible to ignore.
The Automation Imperative: No More Manual Renewals
Here's where things get real for most website operators. With 90-day certificates, you could theoretically get away with manual renewals. Set a calendar reminder every two months, log in, click some buttons, and you're good. It's not ideal, but it's possible.
With 45-day certificates? Forget it.
You'd need to renew every month and a half. Miss that window by even a few days, and your website goes down. Visitors see security warnings. Search rankings drop. Revenue disappears. The margin for error becomes vanishingly small.
This is why automation isn't just recommended anymore—it's mandatory. And I'm not talking about "set it and forget it" either. Proper certificate automation means:
- Automatic detection of expiring certificates
- Automatic issuance of new certificates
- Automatic installation and configuration
- Automatic validation that everything works
- Automatic alerts when something goes wrong
For small websites, tools like Certbot make this relatively straightforward. But for enterprises with hundreds or thousands of certificates across multiple environments? That's where things get complex. You need orchestration, monitoring, and fallback mechanisms. You need to handle certificates for development, staging, and production environments separately. You need to manage certificates for internal systems that aren't publicly accessible.
The good news is that the tooling has matured significantly. What was cutting-edge in 2020 is now standard practice in 2026. But you need to implement it—and test it thoroughly—before the 45-day requirement hits.
Authorization Reuse: The Hidden Security Win
Buried in the announcement is another important change that doesn't get as much attention: authorization reuse is dropping. This is actually a bigger security improvement than most people realize.
Here's how it works currently. When you request a certificate from Let's Encrypt, you first prove you control the domain. This is called authorization. For wildcard certificates or multi-domain certificates, you might need multiple authorizations. Once you have these authorizations, Let's Encrypt lets you reuse them for a period (currently 30 days) when requesting additional certificates.
The problem? If someone compromises your ACME client or gets access to your authorization tokens, they can issue unlimited certificates for your domains until those authorizations expire.
With the move to 45-day certificates, Let's Encrypt is reducing authorization reuse periods significantly. The exact details haven't been finalized, but the direction is clear: shorter certificate lifetimes enable shorter authorization reuse periods, which reduces the attack surface.
Think of it this way: It's not just about making compromised certificates expire faster. It's about making the entire certificate issuance process more resilient to compromise. If an attacker does get in, they have less time to do damage before their access becomes useless.
Practical Steps to Prepare Right Now
Okay, enough theory. Let's talk about what you should actually do. The timeline gives you until February 2028, but trust me—you don't want to wait until 2027 to start preparing. Here's your action plan:
1. Audit Your Current Certificate Landscape
First, figure out what you have. Use tools to scan your infrastructure and identify every SSL/TLS certificate in use. Don't just look at public-facing websites—check internal systems, APIs, microservices, everything. You'll probably be surprised by what you find.
I've seen organizations discover certificates they forgot about, certificates issued to employees who left years ago, even certificates for systems that were decommissioned but never properly cleaned up. This technical debt becomes much more dangerous with shorter certificate lifetimes.
2. Implement or Upgrade Your Automation
If you're not already using automated certificate management, start now. For smaller setups, Certbot with cron jobs might be sufficient. For larger organizations, look at solutions like HashiCorp Vault, Smallstep, or commercial certificate management platforms.
Here's a pro tip: Don't just automate the renewal. Automate the entire lifecycle. That includes monitoring certificate health, rotating keys regularly (not just when certificates renew), and automatically replacing certificates that are approaching certain security thresholds.
3. Test Your Failure Modes
This is where most organizations fall short. They set up automation, assume it works, and never test what happens when things go wrong. What if the CA's API is down during renewal? What if DNS validation fails? What if there's a network partition?
Build redundancy into your system. Have multiple validation methods available (DNS and HTTP, for example). Implement exponential backoff for retries. Set up alerting that triggers before certificates expire, not after.
4. Consider Your Monitoring Strategy
With 45-day certificates, you can't rely on monthly checks anymore. You need continuous monitoring. Tools like Prometheus with appropriate exporters can give you real-time visibility into certificate expiration dates across your entire infrastructure.
But here's the key insight: Don't just monitor expiration dates. Monitor the renewal process itself. Track success rates, failure reasons, and timing patterns. This data will help you identify problems before they cause outages.
Common Mistakes and How to Avoid Them
I've helped dozens of organizations through certificate automation projects, and I've seen the same mistakes repeated. Let me save you some pain:
Mistake #1: Assuming your current automation will "just work" with 45-day cycles. It might, but probably not perfectly. The shorter timeline amplifies any small issues. A script that takes 48 hours to complete renewal? That was okay with 90-day certificates. With 45-day certificates, you're spending over 4% of the certificate's lifetime just renewing it. Test everything.
Mistake #2: Not accounting for rate limits. Let's Encrypt has rate limits to prevent abuse. With 45-day certificates, you'll be hitting their API twice as often. For large organizations, this could become a problem. Plan your renewal schedules carefully, and consider using Let's Encrypt's staging environment for testing.
Mistake #3: Forgetting about dependencies. Your certificates don't exist in isolation. They're tied to your CDN, your load balancers, your WAF, maybe even your web scraping infrastructure if you're automating data collection. Make sure all these systems can handle more frequent certificate rotations.
Mistake #4: Neglecting human factors. Your team needs to understand the new reality. Developers used to manually requesting certificates need training. Operations teams need updated runbooks. Everyone needs to know what alerts mean and how to respond.
The Bigger Picture: Where Certificate Security Is Heading
Let's step back for a moment. The move to 45-day certificates isn't happening in isolation. It's part of a broader trend in web security toward shorter lifetimes, faster rotation, and better automation.
We're already seeing this in other areas. Secrets management tools now recommend rotating API keys every 30-90 days. Cloud providers are pushing for more frequent credential rotation. The principle is the same: Reduce the window of opportunity for attackers.
Some experts are even talking about 7-day certificates or daily certificates. That might sound extreme, but consider this: If automation is perfect and instantaneous, why should certificates last any longer than necessary? The only limit is how fast we can issue and deploy them without breaking things.
This evolution also ties into zero-trust architectures. In a zero-trust world, you don't assume anything is safe—you verify everything, all the time. Short-lived certificates fit perfectly into that model. They're temporary credentials that prove identity right now, not for months into the future.
What This Means for VPN and Privacy Services
If you're using or operating VPN services, this change affects you too. Many VPNs use TLS for their control channels or web interfaces. Some even use certificates for client authentication.
For users, the impact should be minimal if the VPN provider has their automation act together. A service like NordVPN, for example, likely has sophisticated certificate management already in place. But it's worth checking with your provider to ensure they're prepared for the shift.
For VPN operators, the challenge is similar to any other web service: more frequent rotations, more automation, more monitoring. The stakes might even be higher, since certificate problems could prevent users from connecting to the VPN entirely—defeating the privacy protection they're paying for.
Here's a specific consideration for privacy services: Certificate transparency logs. Every certificate issued by a public CA gets logged in public, append-only ledgers. With 45-day certificates, there will be twice as many entries in these logs for the same domain. For privacy-conscious organizations, this creates more metadata. It's not a dealbreaker, but it's something to be aware of in your threat modeling.
Getting Help When You Need It
Not everyone has the in-house expertise to overhaul their certificate infrastructure. And that's okay. The important thing is recognizing when you need help and getting it before you have a production outage.
For smaller organizations or specific tasks, you might hire a security consultant or DevOps engineer on a freelance platform like Fiverr to set up and test your automation. Look for someone with specific experience in ACME and certificate automation, not just general sysadmin skills.
For larger enterprises, this might be a project for your security team, infrastructure team, or a dedicated working group. Whoever takes it on, make sure they have the authority to make changes across all relevant systems. Certificate management often spans organizational boundaries, and you need buy-in from everyone involved.
And don't forget about documentation. However you implement your solution, document it thoroughly. What happens when the person who set it up leaves the company? What happens during an incident at 2 AM? Good documentation isn't just nice to have—it's essential for operational resilience.
Looking Ahead: The 2028 Deadline Is Closer Than It Seems
February 2028 might feel comfortably far away, but infrastructure changes take time. Especially in large organizations. You need time to plan, implement, test, and iterate. You need time to handle edge cases and unexpected dependencies.
My advice? Treat 2027 as your real deadline. Aim to have everything fully automated and tested by the end of 2027. That gives you a buffer for unexpected problems and ensures you're not scrambling as the cutoff date approaches.
Remember, Let's Encrypt is doing this for a reason. Shorter certificate lifetimes are better for security, even if they create some operational challenges. The industry is moving this direction because the alternatives—sticking with broken revocation or trying to build perfect revocation infrastructure—haven't worked.
So start preparing now. Audit your certificates. Automate your renewals. Test your systems. The move to 45-day certificates isn't just a technical change—it's a shift in how we think about trust and identity on the web. And getting it right will make your infrastructure more secure, more resilient, and better prepared for whatever comes next.
Because one thing's certain: The trend toward shorter lifetimes and better automation isn't reversing. If anything, it's accelerating. The organizations that adapt now will be the ones that thrive in this new security landscape. The ones that wait? They'll be playing catch-up while dealing with preventable outages and security incidents.
Your move starts today.
