[1,169 words, 6 minute read time]
When an SSL/TLS certificate fails, users don’t think “hmm, a certificate problem.” They think:
“The site is down.”
Browsers throw scary warnings, apps refuse connections, and many users bounce immediately. That’s why SSL monitoring (certificate expiration monitoring + TLS error detection) is one of the highest-ROI checks you can add—especially if you manage multiple client sites.
This guide explains what certificate monitoring checks, how to set alert windows, the most common SSL failures (renewal, chain, hostname mismatch), multi-domain certificate considerations, and how to troubleshoot SSL-related “down” alerts.
If you also manage DNS health (often tied to cert renewals), pair this with DNS monitoring.
What SSL certificate monitoring checks (and what it doesn’t)
A good SSL certificate monitoring system typically checks:
1) Expiration date
- When the certificate becomes invalid (hard fail)
- Whether you’re inside your alert window (e.g., 30/14/7 days)
2) Certificate validity and trust chain
- Whether the certificate chain is complete
- Whether the certificate is trusted by standard clients/browsers
3) Hostname coverage (SAN/CN match)
- Whether the certificate matches the domain being requested (e.g.,
www.example.comvsexample.com)
4) TLS handshake success
- Whether a client can negotiate TLS successfully (no handshake errors)
5) (Sometimes) Protocol/cipher compatibility
Some tools check for outdated TLS versions or misconfigurations that break older clients (varies by tool).
What SSL monitoring usually does not check by itself
- Your website’s application health (HTTP 500 errors, broken checkout, etc.)
- CDN routing issues or DNS resolution issues (though symptoms can overlap)
That’s why SSL monitoring should complement uptime checks—not replace them.
Alert windows: the 30/14/7 day approach (simple and effective)
Certificates expire on a schedule. You want alerts early enough to fix issues before users see warnings.
Recommended conceptual alert windows
- 30 days: “Heads up” (plan renewal; check automation)
- 14 days: “Action needed” (verify renewal is in progress, validate chain)
- 7 days: “Urgent” (escalate; confirm deployment and coverage)
- 1–3 days (optional): “Last chance” paging for agencies/SaaS
Expiration timeline checklist (copy/paste)
30 days out
- Confirm auto-renew is enabled (ACME/Let’s Encrypt or vendor)
- Confirm domain/DNS challenges are still valid (if using DNS-01)
- Confirm ownership/access to where the cert is installed (CDN/LB/server)
14 days out
- Verify the “next” certificate has been issued (if your system pre-issues)
- Confirm the certificate covers the correct hostnames (
www, apex, subdomains) - Spot-check the chain/intermediate certs
7 days out
- Confirm the new certificate is deployed to all edge locations / load balancers
- Confirm your monitoring sees the new expiration date
- Escalate if anything is unclear
Day of renewal
- Verify handshake success and no browser warnings
- Watch for regional differences (CDN edges sometimes lag)
Common SSL failures (and how they happen)
1) Renewal didn’t happen (automation broke)
Typical causes
- billing issue or account permission change
- ACME challenge failing (DNS/HTTP validation)
- DNS record changes broke validation
- cert issued but never deployed
What it looks like
- everything works… until the expiration moment
- then users see full-page security warnings
2) Incomplete chain (missing intermediate)
Typical causes
- server misconfiguration after renewal
- deploying only the leaf cert without intermediate chain
- platform change (new load balancer/CDN config)
What it looks like
- works in some browsers/devices but not others
- intermittent “certificate not trusted” errors
3) Hostname mismatch
Typical causes
- cert covers
example.combut notwww.example.com(or vice versa) - subdomain added later but cert wasn’t updated
- monitoring checks
wwwwhile cert installed on apex only
What it looks like
- browser warning: “certificate doesn’t match”
- monitoring reports TLS errors on one hostname only
4) Wrong certificate deployed (staging vs prod)
Typical causes
- human error during deployment
- copied config across environments
What it looks like
- sudden TLS warnings after a deploy/config change
- certificate details don’t match expected org/domain
5) CDN/LB partial deployment (multi-edge lag)
Typical causes
- CDN edge propagation delay
- multiple load balancers where only one got updated
What it looks like
- regional TLS failures
- “works for me” from one region but not another
Multi-domain certificate considerations (SANs, wildcard, and scale)
If you manage many domains (agencies) or many subdomains (SaaS), certificate sprawl is common.
SAN (multi-domain) certificates
A SAN certificate can cover multiple hostnames in one cert.
Benefits
- fewer renewal objects to manage
- simpler when many hostnames are always used together
Risks
- if renewal fails, multiple hostnames fail at once
- keeping the SAN list current becomes operational work
Wildcard certificates (*.example.com)
Benefits
- covers many subdomains
- simpler onboarding for new subdomains
Risks
- still does not cover the apex domain (
example.com) unless included separately - often requires DNS-01 validation (DNS changes can break automation)
Practical guidance
- If you have 1–3 hostnames, SAN is fine.
- If you create subdomains frequently, wildcard may reduce operational load.
- For agencies managing many unrelated domains, separate certs per domain is usually cleaner (and less blast radius).
Also consider DNS monitoring because DNS issues often break ACME validation flows: DNS monitoring.
Troubleshooting SSL-related “down” alerts (fast checklist)
When your uptime monitor says “down” and the error looks TLS/SSL-related:
Step 1: Identify the symptom type
- Expired certificate?
- Hostname mismatch?
- Chain/trust error?
- Handshake failure?
Step 2: Confirm which hostname fails
Test both:
https://example.comhttps://www.example.com
A mismatch between the two often means coverage/SAN issues.
Step 3: Check whether it’s regional
If you’re behind a CDN or have multiple load balancers:
- test from another network/location
- compare monitoring regions
Regional inconsistency often means partial deployment or CDN edge lag.
Step 4: Confirm what changed recently
Common change triggers:
- certificate renewal event
- CDN/WAF config change
- load balancer update
- DNS changes (validation issues)
Step 5: Mitigate
- Deploy the correct certificate + full chain
- Fix hostname coverage (update SANs / add separate cert for
wwwor apex) - Roll back the TLS config change if it coincides with the incident
If this is happening during a live incident, follow the first-30-min playbook: incident response.
Symptom table: “what you see” → “likely cause” → “quick fix”
| Symptom | Likely cause | Quick fix |
|---|---|---|
| Browser says cert expired | Renewal failed or wasn’t deployed | Renew + deploy; verify monitoring sees new date |
| Works in some browsers, fails in others | Missing intermediate chain | Deploy full chain/bundle |
www fails but apex works (or vice versa) | Hostname mismatch / SAN missing | Update cert SANs or add separate cert |
| Only one region fails | CDN edge lag / partial LB deployment | Deploy to all edges/LBs; wait for propagation if needed |
| Monitor reports TLS handshake error | TLS config/cipher/protocol issue or wrong cert | Roll back config; validate TLS settings |
If your TLS-related alerts are noisy or confusing due to monitoring misconfiguration, see false positives.
How to use SSL monitoring in an agency context (quick tips)
If you manage many client sites, SSL monitoring is a lifesaver when standardized:
- Tag monitors by client and domain
- Use a consistent alert window policy (30/14/7)
- Route 7-day alerts to a human owner (not just email)
- Keep a “cert ownership” field in your client inventory:
- where the cert is managed (CDN, host, Let’s Encrypt, etc.)
- who has access
- renewal method (DNS-01 vs HTTP-01)
CTA: Set certificate alerts before the next renewal cycle
The worst time to think about certificates is the day they expire.
CTA: Set certificate alerts now (30/14/7 day windows) before the next renewal cycle—because SSL failures look like total downtime to users, and they’re almost always preventable.