How Let's Encrypt changed SSL and created a new monitoring problem
Let's Encrypt brought free, automated SSL to millions of domains. But short-lived certificates and invisible renewal failures introduced a risk most teams don't see coming — until something breaks at the worst possible time.
Free SSL certificates were supposed to make the internet safer. They did. But they also introduced a quiet new risk that catches teams off guard: more certificates expiring, more often, with less visibility than ever.
Here's how that happened, and what it means for anyone managing more than a handful of domains.
The world before Let's Encrypt
Not that long ago, SSL certificates were expensive, slow to provision, and manually installed. You'd pay a certificate authority anywhere from $50 to several hundred dollars per year, wait for a validation process, and then configure your server by hand.
That friction had an upside: teams noticed their certificates. Buying and installing one was an event. Renewal was a line item in a budget. Someone, somewhere, had it on their radar.
The downside, of course, was that huge swaths of the internet ran unencrypted. Small sites, side projects, internal tools, staging environments — if it wasn't worth the money and hassle, it didn't get HTTPS.
What Let's Encrypt fixed
Let's Encrypt launched in 2015 with a simple promise: free, automated SSL certificates for everyone. It delivered on that promise spectacularly. Today it secures over 400 million domains and has fundamentally shifted the web toward encryption by default.
The key innovations were straightforward. Certificates cost nothing. The ACME protocol made issuance and renewal programmable. Tools like Certbot could handle the entire lifecycle without human intervention.
Adoption exploded. Hosting providers, CDNs, and platforms baked Let's Encrypt into their infrastructure. Getting a certificate went from a multi-step procurement process to a checkbox.
By almost any measure, this was a massive win for internet security.
The monitoring problem nobody expected
But something shifted in the process, and it created a new category of risk.
Certificates went from annual to short-lived. Let's Encrypt certificates expire every 90 days. The upcoming industry push is even more aggressive — proposals are on the table for 47-day and even 6-day certificate lifespans. That means a single domain now goes through 4 to 60 renewal cycles per year instead of one.
Automation became a single point of failure. When renewal works, it's invisible. When it breaks, it's also invisible — until a certificate expires and something goes down. A misconfigured cron job, a changed DNS record, a server migration that forgot to bring the Certbot config along. These failures are silent right up until they aren't.
Certificate sprawl became the norm. Because certificates are free and easy to provision, teams spin them up liberally. Staging environments, internal dashboards, microservices, development domains — they all get certificates now. That's good for security, but it means nobody has a clear picture of how many certificates exist or when they expire.
Ownership got murky. When certificates cost money, there was usually a paper trail. Someone approved the purchase. Someone expensed it. With free, automated certificates, there's often no record of who set it up, which server it lives on, or whether the automation that manages it still works.
Where this breaks in practice
The failure pattern is almost always the same. A team sets up Let's Encrypt on a server. Certbot runs. Certificates renew automatically for months or years. Then something changes.
Maybe the team migrates to a new server and forgets to set up auto-renewal. Maybe a DNS provider change breaks the ACME challenge. Maybe a firewall rule silently blocks the validation request. Maybe the person who originally configured it left the company.
The certificate expires. The site shows a browser warning. APIs start rejecting connections. Webhook deliveries fail. Customers see a "not secure" warning and leave. Depending on when it happens and how long it takes to notice, the impact ranges from embarrassing to genuinely costly.
The irony is that teams running paid, manually renewed certificates sometimes catch expirations faster — precisely because the process was never automated in the first place. They expected to do it by hand, so they tracked it.
Why the old approaches don't work anymore
The strategies that worked for one or two annually renewed certificates fall apart at the scale and speed that Let's Encrypt introduced.
Calendar reminders assume you know about every certificate and that one person is responsible. With dozens of auto-provisioned certificates across multiple services, that's rarely the case.
Relying on auto-renewal is not the same as monitoring. It's trusting that a process you can't see is working correctly, every time, across every server and domain. That's not confidence — it's hope.
Checking manually doesn't scale. Even if you could remember to check every domain, doing it every 90 days across a growing list of services is a full-time job nobody wants and nobody does consistently.
What actually works
The answer is dedicated certificate monitoring — something that watches your certificates independently of the system that renews them.
Effective monitoring works like this. It tracks every certificate across all your domains, subdomains, and services in one place. It checks certificates on a regular schedule and knows their expiration dates before you need to think about them. It alerts you with enough lead time to fix issues before they become outages. And it catches problems that auto-renewal can't tell you about: chain issues, weak configurations, certificates that were renewed but deployed incorrectly.
The key insight is that monitoring should be separate from renewal. If the same system that renews your certificates is also the one responsible for telling you something went wrong, you've built a system that fails silently. Monitoring needs to be an independent check — a second pair of eyes that validates everything is working the way you think it is.
The short-lived certificate future
The trend is clear: certificate lifespans are getting shorter, not longer. Apple has pushed for 47-day certificates. Google has signaled support for even shorter durations. The rationale is sound — shorter lifespans limit the damage from compromised keys and force better automation practices.
But shorter lifespans also mean the margin for error shrinks. A 90-day certificate gives you weeks to notice a failed renewal. A 47-day certificate cuts that window roughly in half. A 6-day certificate means a single missed renewal cycle takes you down.
As the industry moves in this direction, monitoring goes from "nice to have" to essential infrastructure. The organizations that will navigate this transition smoothly are the ones that already have visibility into their certificate landscape. The ones that will struggle are those still assuming auto-renewal will handle everything.
The takeaway
Let's Encrypt made the internet dramatically safer. That's not in question. But it also shifted SSL management from a visible, manual process to an invisible, automated one — and invisible processes fail in invisible ways.
If you're running Let's Encrypt (or any automated certificate management), you're not done once auto-renewal is configured. That's where monitoring begins. Because the question isn't whether your automation will eventually fail. It's whether you'll know about it before your users do.