Skip to content

TLS Certificates: When renewal fails, your site goes offline

Let's Encrypt renews automatically. Until it doesn't. And then you're facing an outage nobody saw coming.

TLS is solved. Right?

Let's Encrypt, AWS Certificate Manager, Cloudflare – automatic certificate management is standard today. Free or integrated certificates, automatic renewal, short lifetimes. Problem solved.

Until it stops working.

And then your site is offline. Not because your server crashed. Not because your database is full. But because a certificate expired and the browser shows your users a warning page they'll never click through.

Why automatic renewal fails

The list is longer than you'd think:

• DNS challenge fails because a record changed
• HTTP challenge fails because a reverse proxy was reconfigured
• Certbot cronjob was overwritten during a server update
• Rate limits at Let's Encrypt reached (too many requests)
• Wildcard certificate needs DNS challenge, but the API key to the DNS provider expired
• AWS Certificate Manager can no longer validate the domain because validation records were deleted
• Container was redeployed without the volume containing certificates
• Kubernetes cert-manager has an issue with the issuer config
• Cloudflare integration loses connection to the origin after a configuration change

Each of these cases is real. Each leads to the same result: Certificate expires, site shows error, users are gone.

The time window is small

Let's Encrypt certificates expire after 90 days. Renewal typically happens 30 days before. That means: If renewal fails, you have 30 days to notice.

Sounds like a lot. But if nobody actively checks, you notice on the day of expiry. Or worse: Your users notice before you do.

For certificates with longer lifetimes (1 year), the window is even trickier. Renewal comes up once a year – exactly the point when nobody remembers how it was set up.

The other problem: Unexpected issuances

Missing renewal isn't the only problem. The opposite can be dangerous too: A certificate is issued that you didn't order.

What this can mean:

• Someone gained DNS control and passed the ACME challenge
• An attacker requested a certificate from a different CA
• An old process or forgotten server is still renewing certificates for a domain you've migrated

In every case: A valid certificate for your domain exists that you don't control. Your users' browsers will accept it. No alarm, no error – just a green lock on a page that doesn't belong to you.

What changes and what stays the same

In a healthy certificate, these change regularly:

• The expiration date (with every renewal)
• The serial number (every certificate gets a new one)
• The fingerprint

What should stay the same:

• The issuer (your CA)
• The SANs (Subject Alternative Names – which domains it covers)
• The key type and key size

If the issuer changes, someone got a certificate from a different CA. If the SANs change, the certificate suddenly covers different domains. Both are signals you want to see immediately.

What Driftguard detects

Driftguard monitors your TLS certificates on multiple levels:

Expiry tracking: How many days until expiry? Was it renewed in time? If the certificate approaches its expiration without renewal, you're alerted – not on the day of the outage.

Issuer change: Did the issuing CA change? From Let's Encrypt to an unknown CA? That's a strong signal.

SAN changes: Does the certificate suddenly cover different domains? Or are domains missing that were there before?

Unexpected issuance: A new certificate appears even though the old one was still valid and no renewal was due. Why?

Everything is documented, everything is traceable. So you can see the difference between "renewed on schedule" and "something isn't right here."