Why Certbot Isn't Enough: The Hidden TLS Cert Expiration Problem

Everyone loves Certbot.

It's fast, free, and does a great job keeping your public TLS certificates renewed and your websites green-locked. For personal projects and web-facing services, it's a no-brainer.

But here's the brutal truth: Certbot can't save you from the real certificate expiration nightmares.

The Sunday Morning Nightmare

Let me tell you about the kind of day that's burned into every ops engineer's brain. A backend service suddenly fails to connect to a database. An API integration mysteriously times out. A load balancer throws TLS errors in production. It's Sunday morning. Your Slack is on fire. You're the one with SSH access. And the culprit? A certificate expired. Nobody even knew it existed.

Certbot works great in clean, public environments where everything is web-facing, the certificates come from a CA that supports ACME, and internet access is assumed. But what happens when you're running internal CAs like Microsoft ADCS or Entrust? Or when your infrastructure is air-gapped because of compliance requirements? What about internal mTLS for service-to-service authentication, or embedded certs in devices and firmware? What happens when the cert isn't in a web server at all, but sitting inside a Java Keystore or a config folder on a legacy server?

That's where things break. Certbot isn't designed for these cases.

The Real World Is Messier Than Demos

Neither are most monitoring tools, unless someone took the time to write a custom exporter, hook it into Prometheus, tag the alert correctly, and ensure someone owns it. And let's be honest, that "someone" left the company a year ago.

When a cert expires and causes an outage, the real issue isn't just forgetting to renew. It's that nobody knew who owned the cert. The alert, if it even existed, went to the wrong team. The cert was manually installed on a box during a critical hotfix three years ago and never documented. The person who did it thought they'd circle back and never did.

This Isn't Theory, It's Already Happened

This isn't theory. It's already happened, and at the highest levels:

• Microsoft Teams suffered a global outage in 2020 because someone forgot to renew an authentication certificate. Millions of users couldn't connect.
• Google's second-generation Chromecast and Audio devices stopped working entirely in 2025 due to an expired intermediate CA certificate. An entire ecosystem of consumer electronics bricked for hours because of a missed cert renewal.
• Spotify's Megaphone platform experienced a major outage in 2022 when an expired SSL certificate prevented podcast publishers from accessing their CMS and listeners from downloading episodes.

These are companies with unlimited resources and world-class engineering teams. If it can happen to them, it can happen to anyone.

Where Certbot Falls Short

Certbot is excellent at what it does, but it has fundamental limitations:

ACME Protocol Dependency: Certbot only works with Certificate Authorities that support the ACME protocol. Your internal Microsoft ADCS? Nope. Your vendor's proprietary PKI? Not happening.

Internet Access Requirements: Air-gapped environments are common in finance, healthcare, and government. Certbot needs to phone home to Let's Encrypt or other ACME CAs, making it useless in secure, isolated networks.

Web Server Tunnel Vision: Certbot assumes your certificates live in web server configurations. But modern infrastructure is more complex. What about Java keystores, Windows certificate stores, Kubernetes TLS secrets, database server certificates, load balancer certificates, or embedded device certificates? Certbot doesn't even know these exist.

Discovery Blindness: Certbot manages the certificates it creates, but it doesn't help you discover and monitor certificates that already exist in your infrastructure. It's like having a security system that only watches the front door while ignoring all the windows.

Ownership Vacuum: When a Certbot-managed cert is about to expire, you get an email. But who should actually handle the renewal? Which team owns that service? What's the business impact if it fails? Certbot doesn't care,it just sends the same generic notification to whoever set it up.

The Safety Net Is Gone: Making matters worse, Let's Encrypt ended their expiration notification service in June 2025. They're no longer sending those backup email reminders when certificates are about to expire. If your automation fails, you're flying blind.

The Enterprise Reality

That's the world we built SSL Guardian for. Not the shiny demo environments with terraform-managed ACM. The messy, real-world setups where certs are everywhere, and no one really knows where they all are.

We built it to work with Java keystores and PKCS#12 files, certificate folders and loose PEM files, Windows certificate stores, Kubernetes TLS secrets, AWS Certificate Manager, Azure Key Vault, air-gapped environments with no internet access, and internal PKI from any vendor.

With a small agent called KeyMon, we made it possible to push cert metadata from anywhere,cloud, on-prem, or embedded. The platform gives teams visibility, expiry tracking, ownership context, and real alerts that go to the right people.

The Reddit Reality Check

The Reddit thread where we shared our journey was enlightening. The first 50 replies? "Just use Certbot."

That response made something really clear: we weren't telling the story the right way. Because this isn't about automating renewals. It's about accountability. It's about not getting paged at 2am for a cert you didn't know existed.

Beyond Public Web Certificates

Modern infrastructure is complex. Microservices communicate over mTLS. Databases use TLS for client connections. Load balancers terminate SSL for multiple backends. IoT devices have embedded certificates. VPNs rely on certificate-based authentication. API gateways validate client certificates.

None of these scenarios fit Certbot's model. They require a different approach, one that focuses on discovery, monitoring, and ownership rather than just automated renewal.

What You Actually Need

If you're managing enterprise infrastructure, you need universal discovery to find certificates wherever they live, multi-source support that works with any CA (not just ACME), air-gap compatibility that functions without internet access, ownership tracking so you know who's responsible for each cert, smart alerting that routes notifications to the right teams, and compliance reporting that generates audit trails and reports.

The Bottom Line

We're not claiming to be the only answer. If your current setup works and nothing has blown up yet, great. But if you've lived through the "Sunday Surprise" and you're tired of wondering what cert will break next, maybe it's time to stop duct-taping solutions together.

Certbot is fantastic for what it does. But enterprise certificate management requires more than automated Let's Encrypt renewals. It requires visibility, accountability, and the ability to work with the messy reality of modern infrastructure.

Check out SSL Guardian. Or don't. But don't say you weren't warned the next time prod goes dark because of another forgotten cert.

---

Ready to go beyond Certbot? Start monitoring all your certificates with SSL Guardian and never miss another expiration.