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 — Warn when the certificate drops below your configured threshold (default 30 days), then escalate to a breaking alert inside the final 7 days, and again once it has expired
• Certificate chain validity — Whether the certificate chain authorizes (intermediates valid, not self-signed, not expired)

Rumbliq's SSL check performs a TLS handshake, reads the X.509 certificate, and reports the issuer, subject, expiry date, and days remaining — then evaluates that against your threshold.

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:

1. Add your monitor to Rumbliq with check_ssl enabled
2. Rumbliq checks your certificate on each poll and tracks the expiry date
3. Set ssl_expiry_threshold_days (default 30) — you get a warning at that threshold and an automatic breaking alert inside the final 7 days
4. 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:

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

What to Monitor Beyond Expiry

Rumbliq's SSL check validates two things on every poll, both of which catch problems that a naive "does the cert exist" check misses:

Certificate chain authorization — The chain has to authorize end to end: intermediates served, not self-signed, not expired, and matching the host it's serving. A certificate that exists but doesn't authorize raises a breaking alert.

Expiry with escalation — A warning at your configured threshold (default 30 days), a breaking alert inside the final 7 days, and a breaking alert once it has expired.

Deeper TLS posture checks — enforcing TLS 1.2+ minimums, flagging weak cipher suites, HSTS, certificate transparency, or OCSP revocation — are the job of a dedicated TLS scanner (for example SSL Labs), not Rumbliq's expiry monitor.

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:

1. Inventory first — You can't monitor what you don't know about. Build a complete inventory of domains and subdomains before setting up monitoring.

2. Tiered alert thresholds — Critical production domains: alert at 30+ days. Internal/staging domains: alert at 14 days. Low-criticality properties: alert at 7 days.

3. 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.

4. 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.

Related Posts

• API health check monitoring
• API monitoring complete guide
• API alerting best practices

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