SSL Certificate Expiry Monitoring: Stop Getting Caught by Expired Certs

An expired SSL certificate causes a complete outage. Not a degraded experience. Not some users affected. Every user who tries to reach your service gets a full browser warning page and can't proceed — unless they click through a security warning that most users won't, and shouldn't, ignore.

The worst part: this failure is entirely predictable. SSL certificates have explicit expiry dates. They don't fail suddenly — you can see it coming weeks in advance. Yet certificate expiry is still one of the most common causes of unnecessary outages.

This is what SSL certificate expiry monitoring prevents.

Why SSL Certificates Expire Without Warning (And How Teams Miss It)

Auto-Renewal Doesn't Always Work

Let's Encrypt's automated renewal via certbot or acme.sh is excellent — when it works. But renewal can fail due to:

DNS changes that break the ACME challenge
File permission issues preventing certificate writes
Server configuration changes that interfere with certbot
Port 80 being blocked for HTTP challenge validation
Rate limiting if renewal is attempted too often
Certbot itself having configuration drift

You configure auto-renewal and trust it. Then something changes in your infrastructure, renewal silently fails, and you discover it when the certificate expires.

Certificates Spread Across Infrastructure

Modern teams run certificates in multiple places:

Web servers (nginx, Apache)
Load balancers (AWS ALB, CloudFlare, nginx plus)
CDN edge nodes
Internal services with mTLS
API gateways
Third-party services you use

A renewal policy that works for your main domain might not cover your API subdomain, your staging environment, or your internal monitoring endpoint. One missed certificate causes an outage.

Manual Renewal Gets Lost in Operational Noise

For certificates that aren't on auto-renewal (private CA certificates, wildcard certificates, certificates in legacy infrastructure), renewal is a manual task. Manual tasks get forgotten, especially in high-velocity engineering teams where operational work competes with feature work.

Short-Lived Certificates Require More Frequent Attention

Modern security best practices push toward shorter certificate lifetimes — 90 days for Let's Encrypt, and proposals to move toward 47-day or even shorter windows. The more often certificates expire, the more opportunities for the renewal process to fail.

What SSL Certificate Expiry Monitoring Does

SSL certificate expiry monitoring continuously checks your certificates and alerts you with enough lead time to renew before expiry.

At minimum, it tracks:

Days until expiry — How many days before the certificate expires
Alert thresholds — Alert at 30 days, 14 days, 7 days before expiry
Certificate chain validity — Whether intermediate certificates are valid
Hostname matching — Whether the certificate is valid for the domain it's serving

More comprehensive monitoring also checks:

Weak ciphers or protocols — Whether TLS 1.0/1.1 are still enabled
HSTS headers — Whether HTTP Strict Transport Security is configured correctly
Certificate transparency — Whether certificates are properly logged in CT logs
Revocation status — Whether a certificate has been revoked (OCSP check)

The Full Cost of Expired SSL Certificates

User Impact

Browser SSL warnings are designed to be scary. They're supposed to prevent users from connecting to potentially compromised sites. When your legitimate certificate expires:

Chrome shows a full red error page with "Your connection is not private"
Safari shows "This Connection Is Not Private"
Firefox shows "Warning: Potential Security Risk Ahead"
Mobile browsers typically show even more severe warnings

Most users will not proceed past these warnings. They'll leave, potentially tell others, and may never return.

API Client Impact

For APIs, an expired certificate means:

All API clients using TLS verification will fail (which is all properly-configured clients)
Mobile apps will stop working
B2B integrations will fail
Automated processes will throw connection errors

Unlike browser users, API clients don't have the option to "proceed anyway." An expired cert is a hard outage for API consumers.

SEO Impact

An extended period with an expired certificate can affect search rankings. Google de-prioritizes sites with SSL errors. Traffic drops during the outage may persist even after the certificate is renewed.

Compliance Implications

For regulated industries, a certificate expiry that causes even brief downtime can require incident documentation, breach notification review (was data exposed?), and audit trail updates.

Setting Up SSL Certificate Expiry Monitoring

Using Rumbliq

Rumbliq monitors SSL certificate expiry alongside API monitoring, giving you unified visibility into your API health and certificate status.

Setup steps:

Add your domain(s) to Rumbliq monitoring
Rumbliq checks your certificate on each poll and tracks expiry date
Set alert thresholds: alert at 30 days, 14 days, 7 days remaining
Configure your alert channels (Slack, PagerDuty, email)

You don't need to configure anything special — Rumbliq captures certificate metadata when it makes each monitoring request and surfaces expiry warnings automatically.

Manual SSL Check (One-Off)

# Check certificate expiry date from command line
echo | openssl s_client -connect yoursite.com:443 2>/dev/null | \
  openssl x509 -noout -enddate

# Output:
# notAfter=Apr 25 12:00:00 2026 GMT

# Calculate days until expiry
EXPIRY=$(echo | openssl s_client -connect yoursite.com:443 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
echo "Days until expiry: $DAYS_LEFT"

Automated Check Script (Self-Hosted)

If you want to run your own checks:

#!/bin/bash
# check-ssl-expiry.sh
DOMAIN=${1:-"yoursite.com"}
WARN_DAYS=${2:-30}

EXPIRY=$(echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null | \
  openssl x509 -noout -enddate | cut -d= -f2)

if [ -z "$EXPIRY" ]; then
  echo "CRITICAL: Could not retrieve certificate for $DOMAIN"
  exit 2
fi

EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -le 7 ]; then
  echo "CRITICAL: Certificate for $DOMAIN expires in $DAYS_LEFT days"
  exit 2
elif [ $DAYS_LEFT -le $WARN_DAYS ]; then
  echo "WARNING: Certificate for $DOMAIN expires in $DAYS_LEFT days"
  exit 1
else
  echo "OK: Certificate for $DOMAIN expires in $DAYS_LEFT days"
  exit 0
fi

Certificate Renewal Workflows

Let's Encrypt (Certbot)

# Test renewal (dry run)
sudo certbot renew --dry-run

# Actual renewal
sudo certbot renew

# Set up automatic renewal (systemd timer or cron)
# Most certbot installations create this automatically
# Verify with:
systemctl list-timers | grep certbot

AWS Certificate Manager (ACM)

ACM auto-renews certificates it issued for domains it validates — but auto-renewal can fail if:

Your DNS validation record was deleted
Domain ownership verification fails
The certificate is no longer associated with an active resource

Monitor ACM certificates via CloudWatch metrics or AWS Config.

Manual Certificates (Private CA, Wildcard)

For certificates that require manual renewal:

Set a calendar reminder 60 days before expiry (the monitoring tool's alert is your last resort, not your primary reminder)
Document the renewal procedure in a runbook
Track all certificates in an inventory (spreadsheet, your monitoring tool's dashboard, or certificate management tooling)

What to Monitor Beyond Expiry

SSL certificate monitoring shouldn't stop at expiry dates. Consider also monitoring:

Certificate hostname mismatch — Your certificate is valid but doesn't cover the domain it's serving. Happens when you add a subdomain but forget to update the cert.

Certificate chain issues — Intermediate certificates aren't being served, causing verification failures on some clients even though the end certificate is valid.

Protocol support — Are you still allowing TLS 1.0 or 1.1? These protocols have known vulnerabilities and are deprecated. Modern security standards require TLS 1.2 minimum, TLS 1.3 preferred.

Weak ciphers — Even with TLS 1.2+, cipher suite selection matters. Monitoring tools can flag the use of weak or deprecated cipher suites.

Monitoring Multiple Domains at Scale

If you manage many domains (SaaS platform with customer subdomains, large portfolio of web properties), certificate monitoring needs to scale:

Inventory first — You can't monitor what you don't know about. Build a complete inventory of domains and subdomains before setting up monitoring.
Tiered alert thresholds — Critical production domains: alert at 30+ days. Internal/staging domains: alert at 14 days. Low-criticality properties: alert at 7 days.
Unified dashboard — See all certificates and their expiry status in one view. A table showing domain, expiry date, days remaining, and status gives you immediate operational visibility.
Escalation paths — Know who's responsible for renewing each certificate. A monitoring alert that goes to "the team" often means nobody acts on it.

Getting Started

The most impactful thing you can do right now: find out when your current certificates expire.

For each critical domain, run:

echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -enddate

If anything expires within 30 days, renew it today. Then set up Rumbliq to continuously monitor and alert so you never need to do this manually again.

Certificate expiry is one of the most preventable outages in engineering. There's no reason to be caught by it.

Start monitoring your SSL certificates free → — 25 monitors, no credit card required. Or see plans →