TLS Incidents Have Five Categories. Most Teams Diagnose Each One From Scratch.
TLS incidents look complex because the error messages are unfamiliar to most engineers. They're actually simple - there are five root cause categories, and most TLS incidents map cleanly to one of them. The teams that have internalized that map close incidents in minutes. The teams that haven't spend hours debugging from first principles every time.
Mean time to resolution for TLS incidents is one of the easier metrics to move, because the diagnosis half of MTTR responds well to structured playbooks.
The five categories
Almost every TLS outage falls into one of these:
Expired certificate. The simplest case. notAfter is in the past. Browsers show "your connection is not private" with a date-related error code. Fix: issue and deploy a new cert. If urgency is high, free Let's Encrypt issuance via Beacon takes about 10 minutes.
Broken chain. The cert is valid; the intermediates aren't being sent (or the wrong intermediates are being sent). Modern browsers may handle this via AIA chasing; older clients fail. Fix: serve the full chain. The exact remediation depends on whether you're terminating at nginx, Apache, a load balancer, or a CDN.
Hostname mismatch. The cert's SAN list doesn't include the hostname being requested. Often a wildcard depth issue (a *.example.com cert doesn't cover a.b.example.com), sometimes a SAN truncation during renewal. Fix: reissue the cert with the right SANs.
Untrusted issuer. The cert chains to a CA that the browser doesn't trust. Could be a self-signed cert in production by accident, a private-CA cert reaching a public client, or a public cert chaining through a root that just got distrusted (DigiCert G1 in April 2026 was a notable case). Fix: reissue from a trusted public CA.
Cipher or protocol mismatch. Server only supports TLS 1.0/1.1, or only offers weak cipher suites. Modern browsers refuse to negotiate. Fix: enable TLS 1.2/1.3, modern cipher suites, and OCSP stapling.
That's the entire map. Every TLS incident I've ever seen reduces to one of these five (sometimes two: an untrusted issuer producing a cascade that looks like a chain break, for example).
Structured diagnostics in one command
The fastest path from "site is down" to "I know which category we're in" is a single openssl invocation:
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>&1 | openssl x509 -noout -dates -issuer -subject -ext subjectAltName
That gives you the cert's dates (expiry check), the issuer (untrusted-issuer check), the subject and SANs (hostname-mismatch check), and the full chain (chain-break check). A second invocation with -tls1_2 or -tls1_3 identifies cipher/protocol issues.
Two openssl commands, total time under 30 seconds, narrows the category to one of the five. The fix follows directly.
Alert payloads that include the diagnostic
The single highest-leverage change most teams can make: stop sending alerts that say "site is down" and start sending alerts that say "site is down, the cert chain is broken on edge-3 (intermediate missing), suggested fix is to redeploy the full chain bundle." The diagnosis is automated; the alert carries it.
This compresses MTTR for two reasons. First, the on-call engineer skips the diagnosis step entirely - they go straight to the fix. Second, the alert can be triaged correctly at the first human touch: this is a chain issue, page the platform team; this is a hostname mismatch, page the team that owns the new subdomain.
Alerts without diagnostic content force every responder to redo the diagnosis. At enterprise scale, that's tens or hundreds of engineer-hours per quarter spent re-running openssl against incidents that could have been pre-categorized.
The MTTR you can actually achieve
With structured playbooks and diagnostic-rich alerts, TLS incident MTTR realistically lands in the 5-15 minute range for the four categories that have well-defined fixes (everything except cipher/protocol, which sometimes requires coordination across multiple teams).
Without them, the same incidents commonly take 1-4 hours, mostly spent on diagnosis. The compute and engineering cost difference at scale is large. The customer-experience difference (a 10-minute outage vs a 2-hour outage) is larger.
Compress TLS incident MTTR with structured diagnostics
TLS Radar runs continuous full-handshake validation against every certificate in your inventory and pre-categorizes failures into the five root cause buckets. Alert payloads include the diagnosis and the suggested fix, routed to the team that owns the service. Built for enterprise teams with API integration into your existing alerting and ticketing, SAML/SSO, and pricing tailored to your certificate volume. Tell us about your incident response setup.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.