SSL monitoring: what to actually watch, and the alert thresholds that matter
SSL monitoring isn't just expiry alerts. Broken chains, weak ciphers, hostname mismatches, revocation — what to watch and the thresholds that work.
SSL monitoring: what to actually watch, and the alert thresholds that matter
Most teams use the phrase "SSL monitoring" to mean "alert me before my certificate expires". That alert matters but it is one of about eight things a real SSL monitor checks. This article walks through every failure mode worth alerting on, the thresholds that catch problems early without paging at 3 AM, and what differentiates passing-but-fragile from genuinely-healthy.
What an SSL monitor actually does
A complete SSL check does the following on every run:
- Connects to the host on port 443 (or whichever port you specify).
- Negotiates a TLS handshake with current cipher preferences.
- Pulls the leaf certificate, intermediates, and root.
- Verifies the chain back to a trusted root.
- Checks the leaf certificate's
notBeforeandnotAfterdates. - Verifies the certificate's hostnames match the domain being checked (CN + SAN).
- Checks the certificate signature algorithm.
- Records the cipher suite and TLS version that the handshake settled on.
- Optionally checks OCSP / CRL revocation status.
Each step has its own failure modes and its own alert.
Failure modes worth alerting on
Expiry within a window
The headline alert. Most monitors fire at multiple thresholds — 30, 14, 7, 3, 1 days remaining. Three is the threshold that rules them all: at three days you have just enough runway to catch a manual oversight, escalate to your CA, or roll back a renewal that broke. Past three days you are already incident-managing.
Alerts at 30 and 14 catch broken auto-renewal pipelines before they become emergencies. The 7-day alert is the "okay, who is on this" reminder.
Already expired
Critical alert, fires within the next monitoring run after expiry. Your TLS no longer works for clients that respect dates (which is all current browsers and most automated clients). At this point you are in an outage.
Chain incomplete
The monitor connected, the leaf cert is fine, but the server didn't send the intermediate certificate(s) needed to chain back to a trusted root. Browsers (which carry their own AIA-fetcher logic to find missing intermediates) usually still work. Java, Python's requests with the system certificate store, and many embedded clients fail.
The classic symptom: "the site works in Chrome but our partner's webhook is failing". Fix is to re-export the certificate bundle from your CA and re-deploy with the full chain.
Hostname mismatch
The certificate is valid but doesn't cover the hostname you connected to. Common after a domain migration where the old certificate was deployed to the new host but the SAN list wasn't updated. Causes browser interstitials and outright client failures.
Wildcard certificates can cause subtle mismatches: *.example.com covers www.example.com but not example.com itself, and not api.staging.example.com (only one level of subdomain).
Self-signed certificate detected
The certificate is not signed by a recognized CA. Almost always a deployment mistake — a development certificate accidentally promoted to production. Sometimes intentional in private networks, in which case the alert should be suppressed.
Weak cipher or protocol
The handshake completed but used a deprecated cipher (RC4, 3DES, plain CBC) or a deprecated protocol version (TLS 1.0, TLS 1.1, SSLv3). Browsers will start refusing these in their next major release; security scanners will flag them; PCI-DSS compliance regimes will fail you.
Alert thresholds:
- TLS 1.0 / 1.1 enabled — warning.
- SSLv3 / SSLv2 enabled — critical.
- RC4 / 3DES negotiated — warning.
- NULL / EXPORT cipher reachable — critical.
Signature algorithm weakness
The certificate is signed with SHA-1 (deprecated since 2017) or MD5 (deprecated since forever). Browsers reject SHA-1-signed leaf certificates. Some embedded systems still issue them; if you find one, replace it.
OCSP / CRL revocation
The certificate has been explicitly revoked by the issuing CA. Rare but devastating — typically happens after a private-key compromise or a CA mis-issuance that the CA is cleaning up. Revoked certificates start failing at any client that checks revocation; most browsers do this softly (OCSP-stapling preferred, soft-fail otherwise) but compliance scanners will hard-fail.
Issuer change
The CA that issued your certificate changed since the last check. Could be a normal renewal that picked a different CA, or could be a hostile reissue against your domain. Worth alerting as a notification (not critical), so a human can confirm the change was expected.
Alert thresholds in practice
Conservative defaults that catch real problems without alarm fatigue:
| Failure mode | Severity | Threshold |
|---|---|---|
| Already expired | Critical | Immediate |
| Expiring soon | Warning | 14 days |
| Expiring critically | Warning | 7 days |
| Expiring critically | Critical | 3 days |
| Hostname mismatch | Critical | Immediate |
| Self-signed in production | Critical | Immediate |
| Chain incomplete | Warning | After 2 consecutive checks (filters transient handshake errors) |
| TLS 1.0/1.1 reachable | Warning | After 2 consecutive checks |
| SSLv3 / NULL cipher reachable | Critical | Immediate |
| OCSP revoked | Critical | Immediate |
| Issuer changed | Info | Immediate, single notification |
| Cipher negotiated weakened | Warning | After 2 consecutive checks |
The "after 2 consecutive checks" rule filters most transient handshake errors. Long-running TCP connections fail occasionally; one failure is not yet an alert.
Monitoring multiple endpoints per domain
Most domains serve TLS from multiple endpoints:
example.comandwww.example.com(often the same cert).api.example.com(usually a different cert, often shorter validity).mail.example.com(MTA TLS for STARTTLS — different port, port 25, withSTARTTLSupgrade).imap.example.com/smtp.example.com(mail-client TLS, usually a wildcard).cdn.example.com(CDN-issued certificate, opaque to your renewal pipeline).
Each endpoint can fail independently. A monitor that only checks example.com will miss an expiring api.example.com certificate that handles your webhook traffic. Comprehensive SSL monitoring tracks every TLS endpoint per domain — host, port, expected hostname, and renewal pipeline source.
What separates passing from healthy
A certificate can pass every check above and still be operationally fragile. Signs that distinguish "valid right now" from "you can rely on it":
- Auto-renewal tested in the last 90 days. Letting a year pass between renewals is a year of drift in your renewal pipeline — by the time you discover the breakage you have hours of runway.
- Renewal failure alerts go to a team, not a person.
webmaster@aliases, individuals' emails — both are how every "expired SSL" outage starts. - Validity period under 90 days. Lets Encrypt's 90-day validity turns out to be a feature: you can't accumulate years of "it works" comfort, so the renewal pipeline gets exercised constantly. CA Browser Forum is moving the industry toward shorter validity (47 days proposed for 2027) for the same reason.
- OCSP stapling enabled. Reduces revocation-check latency at the client and protects you from CA OCSP outages.
- HSTS deployed and stable. Locks browsers into HTTPS for your domain. If your certificate breaks, HSTS turns the warning into a hard refusal — making the outage visible to you, not just degrading user experience silently.
- Certificate Transparency logs monitored. CT logs publish every certificate issued for your domain. Watching them catches mis-issuances you didn't authorize.
Building this yourself vs. using a service
Single domain, one or two endpoints, self-managed certificate: a 30-line cron script with openssl s_client and a Slack webhook is fine. Maintenance overhead is near zero.
Five+ domains, multiple endpoints, multiple renewal pipelines: roll-your-own becomes the second-most-fragile thing in your operations after the certificates themselves. The script is fine; the alerting goes stale, the host running cron migrates, the threshold logic creeps; you discover it failed three months ago when the next certificate expires unannounced.
The break-even point is usually around the same time you start feeling renewal anxiety — five domains, one renewal pipeline you didn't set up, one CDN-issued certificate that nobody on the current team owns.
How DomainCare's SSL check works
DomainCare runs the SSL check on every domain every 6 hours by default (Pro and Business plans can override this per domain). The check connects to port 443, negotiates TLS, pulls the certificate, verifies the chain, checks notAfter against the alert thresholds above, parses the cipher and protocol, and inspects the SAN list against the configured hostname.
Endpoints beyond port 443 (mail TLS, custom ports) are configurable per domain. Cipher and protocol thresholds match the CA Browser Forum recommendations as of the last update.
Default expiry alerts fire at 30 / 14 / 7 / 3 / 1 days. You can override per domain — production domains tend to want the full ladder, marketing micro-sites are fine with a single 7-day alert.
Related
- SSL certificate types compared — DV vs OV vs EV, wildcards, multi-domain.
- SSL certificate expired: what to do — recovery if you missed every alert.
- SSL check reference — what DomainCare's SSL check verifies on every run.
Common questions
My certificate is technically valid but a security scanner is failing me on cipher strength. What changed? Cipher recommendations move. TLS 1.2 is the floor; TLS 1.3 is preferred. Cipher suites without forward secrecy (TLS_RSA_*) are increasingly flagged by scanners even though they're still TLS 1.2-compatible. The fix is the cipher list on your web server — most major distributions ship a default that has drifted from current best practice.
Should I monitor my CDN's certificate? Depends on whether you control it. If your CDN issues and rotates certificates automatically (Cloudflare Universal SSL, AWS CloudFront with ACM), monitoring it tells you the CDN is functioning — useful, but it's an external dependency, not something you control. Alert on CDN cert changes; don't page on them.
My private CA-signed cert keeps showing "untrusted" even though it works inside our VPN. The monitoring service has to trust your CA. Most public SSL monitors won't. For private/internal-only services, run an internal monitor with your CA cert in its trust store, or skip TLS monitoring on those endpoints (they don't expose to the public internet anyway).
Is OCSP stapling worth the trouble? Yes for high-traffic public services. It removes a per-client OCSP lookup latency and protects you from CA OCSP outages. The configuration is a one-time effort; the operational cost is near zero once enabled.