Why SSL Certificates Still Expire in 2026 (And How to Never Let It Happen Again)

SSL certificate expiry should be a solved problem. Let's Encrypt has been free and automatic for a decade. Every major cloud provider offers managed certificate renewal. And yet certificate expiry is still in the top 10 causes of SaaS outages in 2026.

The reason is not that engineers forget to renew. It's that auto-renewal fails in specific, predictable ways — and the failure is silent until the certificate actually expires and your site starts returning SSL errors to users.

This guide covers the 5 most common auto-renewal failure modes, the alert threshold strategy that catches them before users notice, and the monitoring setup that makes certificate expiry incidents practically impossible.

Why Auto-Renewal Fails: The 5 Failure Modes

Failure Mode 1: Domain Validation (ACME Challenge) Failure

Let's Encrypt's auto-renewal works by sending an HTTP challenge request to yourdomain.com/.well-known/acme-challenge/[token]. If your server returns the correct response to this request, the certificate is issued.

This breaks when:

• A WAF or CDN rule blocks requests to /.well-known/ paths
• A redirect (HTTP to HTTPS, www to non-www) breaks before the challenge files are served
• The web server configuration for challenge file serving changes after a deploy
• The server is temporarily down during the renewal window

Diagnosis: Check Certbot or your ACME client logs during the renewal window. The error will appear as acme: Error -> 403 or acme: Error -> connection refused.

Prevention: Test the ACME challenge path before it matters. curl http://yourdomain.com/.well-known/acme-challenge/test should return a 404 or 200 — never a redirect loop or 403.

Failure Mode 2: Certbot Systemd Timer Silently Failing

The most common Let's Encrypt setup on Ubuntu/Debian uses a systemd timer (or cron job) to run certbot renew twice daily. This timer silently fails when:

• The system disk is full (renewal requires temporary file writes)
• The Certbot snap is outdated and refuses to run
• The systemd timer is disabled by a system update
• The Python virtual environment for Certbot is broken

Diagnosis: systemctl status certbot.timer and journalctl -u certbot. If the timer hasn't run successfully in the last 7 days, the renewal process is broken.

Prevention: External monitoring. An SSL expiry monitor that checks your certificate's expiry date from outside the server gives you advance warning even when the internal auto-renewal mechanism is silently broken.

Failure Mode 3: Load Balancer Certificate Not Linked to Auto-Renewal

If you're behind a load balancer (AWS ALB, GCP Load Balancer, Cloudflare, etc.), your SSL certificate terminates at the load balancer — not at your origin server. Certificates configured directly in a load balancer are often renewed manually or through a cloud-specific mechanism that's separate from any Let's Encrypt setup on your origin.

Teams frequently:

• Renew the certificate on the origin server but not on the load balancer
• Have auto-renewal set up for the origin but not the load balancer's certificate
• Use different certificates for origin vs load balancer and only monitor one

Prevention: Verify that your external SSL check (checking from the browser's perspective, through the load balancer) is monitoring the actual certificate users see. PingSLA's SSL + DNS Hunter checks the certificate from the public internet, not from inside your infrastructure — it tests the certificate that users actually receive.

Failure Mode 4: Wildcard Certificate Renewal Requires DNS Verification

Wildcard certificates (*.yourdomain.com) require DNS-01 ACME challenges rather than HTTP-01. DNS-01 renewal requires your ACME client to automatically create DNS TXT records during renewal.

This breaks when:

• DNS API credentials expire or are rotated
• DNS provider changes (migration from Route53 to Cloudflare, etc.) without updating Certbot DNS plugin configuration
• The DNS propagation time exceeds the ACME challenge timeout

Prevention: Test DNS-01 renewal explicitly before the certificate expires. Maintain DNS API credentials in a secrets manager with rotation alerts.

Failure Mode 5: Staging Environment Certificate Contaminating Production

Teams that run staging and production on the same domain or adjacent subdomains sometimes encounter certificate rate limiting. Let's Encrypt has a rate limit of 50 certificates per registered domain per week. If your CI/CD pipeline is issuing new certificates for staging environments (e.g., staging-deploy-123.yourdomain.com) at high frequency, the rate limit prevents production certificate renewal.

Prevention: Use a separate domain or subdomain for staging (e.g., staging.internal.company.com), configure staging to use a single wildcard certificate rather than per-deploy certificates, or use Let's Encrypt's staging environment for non-production certificate issuance.

Alert Threshold Strategy

The goal is never to be surprised by a certificate expiry. This requires a tiered alert threshold strategy:

The 30-day alert is the one that prevents incidents. If you receive a 30-day warning and investigate immediately, you have enough time to diagnose and fix any auto-renewal failure mode before it becomes an outage.

Configure this tier in PingSLA's SSL monitoring by setting alert thresholds at 30, 14, 7, and 3 days on your SSL check.

Checking SSL Certificate Expiry

Via OpenSSL (from your terminal):

# Check certificate expiry for any domain
echo | openssl s_client -servername yourdomain.com \
  -connect yourdomain.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Output:
# notBefore=Jan  1 00:00:00 2026 GMT
# notAfter=Apr  1 00:00:00 2026 GMT

Via curl (check expiry header):

# Get certificate expiry in human-readable form
curl --insecure -v https://yourdomain.com 2>&1 | \
  grep -E "expire|start date|issue date"

Via PingSLA API (for programmatic monitoring):

# Check SSL status via PingSLA
curl -s "https://tools.pingsla.com/api/tools/ssl/check" \
  -H "Content-Type: application/json" \
  -d '{"domain":"yourdomain.com"}' | \
  jq '.ssl.daysUntilExpiry'

For ongoing automated monitoring, run the free SSL + DNS Hunter — it checks your certificate, issuer, chain validity, and HSTS configuration in 30 seconds without requiring any account setup.

Certificate Monitoring vs SSL Monitoring: The Difference

Certificate monitoring checks that your SSL certificate is:

• Currently valid (not expired)
• Issued by a trusted CA
• The certificate chain is intact
• The domain name matches
• Expiry is at least N days away

SSL configuration monitoring checks that your SSL setup is:

• Using modern TLS protocols (TLS 1.2+ minimum, TLS 1.3 recommended)
• Not using deprecated cipher suites
• HSTS header present and correctly configured
• HTTP to HTTPS redirect working correctly
• Certificate includes all necessary SANs (Subject Alternative Names)

You need both. A certificate that hasn't expired but is using TLS 1.0 will fail PCI-DSS compliance. A certificate with correct TLS configuration but a missing SAN will cause browser certificate warnings for users accessing via specific subdomains.

PingSLA's SSL + DNS Hunter checks both categories in a single scan.

How do I set up SSL certificate monitoring with 30-day advance warning?

In PingSLA, create an SSL check for your domain and configure alert thresholds at 30 days (warning) and 7 days (critical). The monitor runs daily and alerts you when the certificate's days-remaining drops below your thresholds. For multi-domain monitoring, add each domain as a separate SSL check — PingSLA includes SSL monitoring in all plans starting from Starter.

Can I monitor SSL certificates for subdomains separately from the main domain?

Yes, and you should. Each subdomain that serves users (app.yourdomain.com, api.yourdomain.com, checkout.yourdomain.com) should have a separate SSL check, because each may use a different certificate with a different expiry date. If you have a wildcard certificate covering all subdomains, you still benefit from per-subdomain monitoring because the wildcard certificate itself may have auto-renewal failures that only manifest when checked against specific subdomains.

What happens to users when an SSL certificate expires?

When a certificate expires, browsers display a full-page error: "Your connection is not private" (Chrome) or "Warning: Potential Security Risk Ahead" (Firefox). This is not a degraded experience — it is a complete blocker for most users. The vast majority of users do not proceed past an expired certificate warning. For a checkout page, an expired certificate means zero revenue until the certificate is renewed.