Use the failure layer as the first routing signal
The fastest TLS incident response starts by separating reachability from certificate validation. If DNS fails, the renewal owner may not be the right person. If the TCP connection fails, the certificate may be fine. If the handshake succeeds but validation fails, the endpoint is reachable but not trustworthy for the hostname.
| Failure class | What it usually means | Who starts |
|---|---|---|
| DNS | The hostname does not resolve, resolves inconsistently, or points somewhere unexpected. | DNS owner, registrar, hosting provider, or platform team. |
| TCP | Port 443 is unreachable, filtered, down, or not listening. | Network, firewall, load balancer, or server owner. |
| TLS handshake | The server and client cannot negotiate TLS or the endpoint needs a different SNI/protocol setup. | Load balancer, reverse proxy, ingress, or TLS configuration owner. |
| Hostname mismatch | The certificate SAN list does not cover the hostname being checked. | Certificate requester, CDN owner, or platform team. |
| Expired or not yet valid | The certificate validity window is outside the current time. | Renewal owner or deployment owner. |
| Trust chain | The server did not present a chain clients can validate. | Server, CDN, certificate bundle, or CA account owner. |
Do not hide certificate failures behind uptime language
A website can return an HTTP response and still have certificate risk. It can also fail a TLS validation check while the origin server is technically reachable. Good monitoring keeps the certificate result visible instead of flattening everything into up or down.
- Hostname mismatch points to SAN coverage, SNI, or the wrong certificate binding.
- Expired and not-yet-valid failures point to validity windows or system time problems.
- Trust-chain failures point to missing intermediates, wrong chain order, unsupported roots, or origin/CDN certificate configuration.
- Handshake failures point to listener, protocol, cipher, mTLS, SNI, or load balancer behavior.
Run a quick external check
When a monitor reports a TLS failure, reproduce the public handshake before changing renewal files. The goal is to inspect what the public endpoint serves, not what the local server has on disk.
HOST=www.example.com
openssl s_client -connect $HOST:443 -servername $HOST -verify_hostname $HOST -showcerts </dev/null- Use the same hostname customers use in both -connect and -servername unless you are intentionally testing an origin IP with SNI.
- Look for the certificate subject, SANs, issuer, validity dates, and verify return code.
- If a CDN is in front, decide whether you are testing the edge certificate or a direct origin path.
Know the common certificate-specific fixes
Once the network path is healthy, most certificate failures fall into a short list of fixes. The details matter because the wrong fix can make the site reachable but less secure, such as switching a proxy out of strict validation instead of replacing a bad origin certificate.
| Symptom | Likely cause | Practical fix |
|---|---|---|
| ERR_CERT_DATE_INVALID | The certificate is expired, not yet valid, or an old certificate is still being served. | Renew or reissue, deploy to every TLS termination point, reload services, and verify the public fingerprint changed. |
| ERR_CERT_COMMON_NAME_INVALID | The SAN list does not include the hostname. | Reissue with the missing hostname or change DNS/SNI so the hostname reaches the right certificate. |
| Unknown issuer or authority invalid | Self-signed certificate, missing intermediate, or origin-only certificate exposed to browsers. | Install the correct full chain or use a publicly trusted certificate for direct browser traffic. |
| Version or cipher mismatch | Unsupported TLS version, cipher issue, or in some CDN cases a hostname not covered by an active edge certificate. | Check edge certificate status, hostname coverage, proxying, and TLS settings before changing the origin. |
| Certificate changed unexpectedly | Renewal, CDN migration, CA change, or wrong binding. | Review issuer, SANs, serial, fingerprint, validity, and deployment timeline before closing the event. |
Make alerts actionable
A useful TLS alert includes the hostname, failure class, last successful certificate snapshot, current probe result, severity, and alert delivery path. Without that context, the first responder spends the first minutes rerunning DNS, curl, browser, and OpenSSL checks.
- Put DNS and TCP failures in a different triage queue from expiry and SAN failures.
- Route final-week expiry and validation failures to watched operational channels.
- Keep previous certificate metadata so certificate changes can be reviewed after renewals and platform moves.
- Record delivery attempts so missed warnings do not become invisible alert-channel failures.
Where Domain Trust Watch fits
Domain Trust Watch classifies public certificate checks into DNS, TCP, TLS handshake, hostname, active-window, expiry, and trust-chain outcomes. That makes alerts easier to route and gives teams a certificate snapshot to review before they open a terminal.
- Use monitor events to see whether the problem is reachability or certificate validation.
- Use certificate snapshots to compare issuer, SANs, serial, fingerprint, chain depth, and validity dates.
- Use Slack, email, or signed webhooks to send different failure classes to the right workflow.