Why Auto-Renew Isn't Enough for SSL Certificates

You set up Certbot, watched it renew successfully once, and moved on to the next task. Auto-renewal is configured. Problem solved. Except three months later, your certificate quietly expires and your site goes down at 2 AM on a Saturday. Auto-renewal was supposed to handle this. It didn't.

This happens more often than anyone admits. Auto-renewal is a great first step, but treating it as the only step is how production outages happen.

The Set-and-Forget Myth

The promise of auto-renewal is appealing: configure it once, and certificates renew themselves forever. Let's Encrypt and Certbot popularized this model, and for good reason. Manual certificate renewal is tedious, error-prone, and easy to forget.

But "automated" doesn't mean "infallible." Auto-renewal is software running on infrastructure, and both change over time. The renewal that worked perfectly six months ago can fail silently today because something in the environment shifted.

Here are the six most common ways auto-renewal breaks down.

Failure Mode 1: The ACME Client Stops Running

This is the most common failure. Certbot (or whatever ACME client you use) simply stops executing.

How it happens:

• You migrate to a new server and forget to set up the cron job or systemd timer
• A system update removes or disables the cron entry
• The container gets rebuilt from an image that doesn't include Certbot
• Someone upgrades the OS and the old cron format is no longer valid

Why it's silent: Nothing errors out because nothing runs. No process, no logs, no alerts. The certificate just quietly approaches its expiration date while everyone assumes it's being handled.

# Check if your Certbot timer is actually running
systemctl list-timers | grep certbot

# Or check if the cron job exists
crontab -l | grep certbot

If either of those comes back empty after a server migration, your auto-renewal is gone.

Failure Mode 2: DNS Changes Break Validation

Let's Encrypt validates that you control a domain before issuing a certificate. If you use HTTP-01 validation, the ACME client places a file on your web server and Let's Encrypt fetches it. If you use DNS-01, a TXT record gets created.

How DNS changes break this:

• You move your domain to a new DNS provider but don't update the DNS-01 API credentials
• You put the site behind a CDN (like Cloudflare), and HTTP-01 challenges no longer reach your origin server
• Your DNS API token expires or gets rotated
• Someone changes DNS records and the validation path breaks

Failure Mode 3: Rate Limits

Let's Encrypt enforces rate limits to prevent abuse. These limits are generous for most use cases, but they can bite you at scale.

Key limits:

• 50 certificates per registered domain per week
• 5 duplicate certificates per week
• 300 new orders per account per 3 hours

How you hit them:

• You have a lot of subdomains and something triggers mass re-issuance
• A broken renewal script retries aggressively instead of backing off
• You're testing in production instead of using the staging environment
• Multiple team members or systems try to renew the same certificate

Once you hit a rate limit, you're locked out for a week. If your certificate expires during that window, there's no override.

Failure Mode 4: Firewalls Block Validation

HTTP-01 validation requires Let's Encrypt's servers to reach your server on port 80. DNS-01 requires API access to your DNS provider. Both can be blocked.

Common blockers:

• A new firewall rule blocks inbound port 80 traffic
• A WAF (Web Application Firewall) blocks the .well-known/acme-challenge/ path
• Geographic IP restrictions block Let's Encrypt's validation servers
• A security team tightens outbound rules, blocking API calls to the DNS provider

These changes often happen months after the initial certificate setup, made by people who don't know about the auto-renewal dependency.

Failure Mode 5: Server Access Changes

Certbot needs write access to specific directories and the ability to reload your web server. When permissions change, renewal fails.

What goes wrong:

• File permissions on /etc/letsencrypt/ change after a security hardening script runs
• The web server (Nginx, Apache) configuration changes and the reload hook fails
• A new deployment process overwrites the webroot directory
• The user running Certbot no longer has sudo access to restart the web server

The sneaky part: Certbot might successfully obtain the new certificate but fail to deploy it. The certificate file exists, but the web server is still serving the old (expiring) one. Renewal technically succeeded, but your site will still go down.

# Test that renewal actually works end-to-end
sudo certbot renew --dry-run

The --dry-run flag simulates the entire renewal process without actually issuing a certificate. Run it after any server changes.

Failure Mode 6: Email Validation for Paid Certificates

Not everyone uses Let's Encrypt. If you have paid certificates from DigiCert, Sectigo, or another commercial CA, "auto-renewal" often means "we'll send you an email when it's time to renew."

The problem:

• The email goes to the person who originally bought the certificate -- who left the company two years ago
• It lands in a shared inbox nobody checks
• It goes to spam
• The renewal requires manual steps (re-validation, payment) that the email recipient doesn't know how to complete

This isn't really auto-renewal at all. It's a reminder system, and it only works if the right person sees it and acts on it.

Why Monitoring Is the Safety Net

Auto-renewal handles the happy path. Monitoring handles everything else.

A monitoring tool doesn't care how your certificate gets renewed. It checks the actual certificate being served by your domain and tells you when it's approaching expiry. If auto-renewal works perfectly, monitoring stays quiet. If auto-renewal fails for any reason, monitoring catches it.

The Right Approach: Defense in Depth

The best certificate management strategy layers multiple protections:

1. Auto-renewal as the primary mechanism -- set up Certbot, acme.sh, or your provider's automation
2. Monitoring as the safety net -- verify that the certificate being served is actually valid and not approaching expiry
3. Regular audits of your renewal infrastructure -- quarterly checks that cron jobs exist, credentials work, and test renewals succeed

Auto-renewal prevents 90% of certificate expiry incidents. Monitoring catches the other 10% -- which is exactly the 10% that would otherwise become a production outage at the worst possible time.

Don't choose between automation and monitoring. Use both.

Auto-renewal is the seatbelt. Monitoring is the airbag. You want both.