SSL Certificate Monitoring: How to Never Miss an Expiry Again

An expired SSL certificate takes your site offline in about the most embarrassing way possible: every visitor gets a browser security warning instead of your homepage. It is fully preventable. Yet it happens to organizations of every size, regularly. Here is what to monitor, how to set up alerts, and the one thing teams consistently get wrong.

What actually breaks when SSL expires

The immediate effect is obvious: HTTPS connections fail. Browsers display "Your connection is not private" (Chrome) or "Warning: Potential Security Risk Ahead" (Firefox) and by default do not allow users to proceed on modern browser versions without manual override.

The secondary effects are worse:

• API clients break silently. Mobile apps and server-to-server integrations using certificate validation will fail with connection errors — often with no user-visible message, just silent failure.
• Google deindexes affected pages. Googlebot respects certificate errors. Pages served over a broken HTTPS connection will not be crawled until the certificate is renewed.
• Email delivery may be affected if your MX servers share the expired certificate or if STARTTLS connections to your mail server fail validation.
• CDN and WAF configurations break. If your origin certificate expires and your CDN is configured to validate the origin, the CDN begins returning 502s even while the CDN edge certificate is still valid.

Why certificates expire despite auto-renewal

Most teams assume Let's Encrypt auto-renewal covers them. It often does — until it does not. Common failure modes:

• DNS validation fails silently. If the ACME challenge DNS record fails to propagate before the validation attempt, renewal fails. The renewal tool logs the error but often does not page anyone.
• The renewal job runs but the web server is not reloaded. A successful certbot renew followed by a failed nginx -s reload (permissions issue, syntax error in a config that was modified) means the old cert keeps serving until someone notices.
• Certificates on subdomains not covered by auto-renewal. The main domain renews; a staging subdomain or API endpoint does not, because it was provisioned manually two years ago and forgotten.
• Certificates from paid CAs or corporate PKI often have no auto-renewal at all. One-year or two-year manual renewals are commonplace in enterprise environments.

What to monitor beyond expiry

Expiry date is the most urgent signal, but a complete SSL audit covers several other dimensions:

Chain completeness

A certificate is only trusted if the full chain from leaf to root is presented during the TLS handshake. Missing intermediate certificates are one of the most common SSL misconfigurations. They usually work in desktop browsers (which cache intermediates) but fail on mobile browsers, cURL, and API clients that do strict chain validation.

The symptom: your site works in Chrome on macOS but returns an SSL error in your Android app or from a CI runner.

Protocol support

TLS 1.0 and 1.1 are deprecated and disabled in all modern browsers as of 2020. If your server still supports them as a fallback (often a leftover Nginx directive from 2015), you are failing PCI DSS compliance and potentially exposing connections to BEAST and POODLE downgrade attacks.

The correct modern configuration supports only TLS 1.2 and TLS 1.3. TLS 1.3 should be preferred as it eliminates the RSA key exchange, requires Perfect Forward Secrecy, and reduces handshake round trips from two to one.

Cipher suite selection

The cipher suite negotiated during the TLS handshake determines the encryption algorithm used for the session. Weak cipher suites to remove:

• RC4 — broken, should not appear in any production configuration
• 3DES / DES — vulnerable to SWEET32 birthday attack
• NULL cipher suites — provide authentication but no encryption
• EXPORT cipher suites — deliberately weakened, affected by FREAK and Logjam

HSTS configuration

HTTP Strict Transport Security tells browsers to only connect to your domain over HTTPS for a specified period. A minimal HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Two common gaps: a max-age that is too short (under 6 months provides limited protection) and missing includeSubDomains (allows attackers to serve HTTP content on subdomains and set cookies that affect the main domain). Adding preload and submitting to the HSTS preload list provides the strongest protection.

Alert thresholds that actually work

Most SSL monitoring tools alert at 30 days. That is too late for organizations with slow change management processes. The recommended sequence:

1. 60 days: low-priority notification. Renewal should be on the schedule.
2. 30 days: normal-priority alert. Renewal should be in progress or scheduled.
3. 14 days: high-priority alert. Renewal must happen this week.
4. 7 days: critical alert. Escalate to engineering leadership if renewal has not started.
5. Cert changed unexpectedly: immediate alert. Could indicate a compromised server or certificate issuance from an unauthorized CA.

The last alert type — unexpected certificate replacement — is often overlooked but catches a distinct class of incident: either a security breach or a misconfigured deployment that rolled the wrong certificate.

Monitoring with Kuality

Kuality performs a full TLS handshake against your domain on every scan: it checks the days until expiry, validates the certificate chain, identifies the protocol version and cipher suites negotiated, and checks HSTS header configuration. Schedule monthly scans and you get alerted at your configured threshold — before the cert becomes an incident.

Check your SSL certificate free →