SSL Expiry Alerts

SSL certificate expiry is one of the most avoidable causes of production outages. Certificates expire on a fixed date known months in advance — yet teams are still caught off guard when a certificate lapses, browsers display “Your connection is not private”, and users can't reach the service at all.

This happens for one reason: no one set up an alert.

What happens when an SSL certificate expires

When a TLS certificate expires, every browser and HTTP client refuses to connect. Users see a security warning and most won't proceed past it. From a monitoring perspective, your uptime monitor starts receiving connection errors rather than HTTP responses — a complete outage with zero code changes.

The impact is immediate and total:

• Web traffic drops to near zero — users can't load the page at all.
• API clients fail with TLS handshake errors.
• Mobile apps stop working.
• Search engine crawlers mark the site as broken.

Remediation requires renewing and redeploying the certificate — which can take 15–60 minutes even with the right tools. The outage window is entirely preventable.

AWS Certificate Manager: auto-renewal

If you're running behind CloudFront, ALB, or API Gateway, use AWS Certificate Manager (ACM). ACM issues certificates for free and renews them automatically — at least 60 days before expiry — as long as your domain validation remains valid.

ACM certificates will not auto-renew if:

• DNS validation records have been removed from Route 53.
• The domain is no longer pointing to AWS resources.
• You used email validation instead of DNS validation.
• The certificate isn't actively in use by an AWS resource.

For ACM certificates, set a CloudWatch alarm on the DaysToExpiry metric:

aws cloudwatch put-metric-alarm \
  --alarm-name "acm-cert-expiry-warning" \
  --namespace "AWS/CertificateManager" \
  --metric-name DaysToExpiry \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:... \
  --statistic Minimum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 30 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:your-alerts-topic

This gives you a 30-day warning even if ACM's auto-renewal somehow fails.

Third-party certificates: manual monitoring required

Certificates installed on EC2 instances, on-premises servers, or managed by a CA outside ACM don't auto-renew. You need an external process to monitor expiry and alert your team with enough lead time to act.

The simplest check is a curl command you can run in CI or a cron job:

# Check days remaining on a certificate
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null \
  | openssl x509 -noout -enddate

# Output: notAfter=Aug 15 12:00:00 2026 GMT

For production systems, you want:

• An alert at 60 days — enough time to initiate renewal through any CA.
• A second alert at 14 days — a final warning if the first was ignored.
• An alert at 3 days — critical, treat as an incident.

External SSL monitoring

Relying solely on internal checks misses one important failure mode: the certificate might be valid but not serving correctly from a user's perspective. This can happen when:

• The certificate chain is incomplete (missing intermediate CA).
• The certificate covers www.yourapp.com but not yourapp.com (or vice versa).
• A CDN or proxy layer is serving a different certificate than your origin.
• Certificate pinning in mobile apps rejects an otherwise valid new certificate.

An external uptime monitor that makes HTTPS requests against your production domain catches all of these — because it validates the certificate exactly as a browser would. If the TLS handshake fails for any reason, the check fails and you're alerted.

PulseRadar monitors your HTTPS endpoints from outside your infrastructure. A certificate that fails validation in the TLS layer will cause the monitor check to fail, triggering an immediate incident and alert — before your users encounter the browser warning.

SSL monitoring checklist

• Use ACM for all CloudFront, ALB, and API Gateway endpoints.
• Use DNS validation (not email validation) for ACM auto-renewal.
• Set a CloudWatch alarm on ACM's DaysToExpiry at 30 days.
• For non-ACM certificates, configure alerts at 60, 14, and 3 days before expiry.
• Run an external HTTPS monitor to catch TLS chain and SNI errors.
• Review all certificates in your account quarterly with aws acm list-certificates.

SSL expiry is a solved problem — the solution is alerts, not luck. Set them up once and you'll never have an expired certificate outage.