TLS Troubleshooting From the Outside: Certificates, Names, and Handshakes

Start with what the server actually presented

TLS failures come in layers, and the fastest path is checking them in order: name, validity, chain, protocol. Probe the endpoint with the TLS Configuration Checker and read the certificate name match first — the presented certificate must cover the exact host you asked for, via SAN entries, not the Common Name that clients stopped honoring years ago. Then validity dates, then whether the negotiated protocol and legacy-version support look like a maintained configuration.

Probe by hostname, never by IP. Modern servers choose their certificate from the SNI value in the handshake; an IP probe shows the default virtual host's certificate, which can differ completely from what browsers receive. This one detail explains a whole family of ghost incidents — the monitoring system that probes by IP and alarms on a certificate no user has ever seen.

The mismatch patterns and what they mean

A wrong-name certificate immediately after a migration means the new frontend, load balancer, or CDN edge never received the right certificate — the DNS cutover worked, the certificate deployment did not. A certificate for a hosting provider's default domain means SNI routing is broken or the vhost mapping lost your name. And a certificate that differs between your probe and a user's browser usually means a CDN serves different edges differently, or a middlebox is interposing — both worth knowing precisely.

Chain problems produce the classic works-here-fails-there split. Browsers repair incomplete chains by fetching missing intermediates or using cached ones; strict API clients, older Java stacks, and embedded devices do not. When curl fails while browsers succeed, suspect a missing intermediate before anything else. Decode the presented chain with the SSL Certificate Decoder to see issuer, SAN coverage, and chain order without leaving the browser.

Key rotation has a quieter blast radius: anything that pins keys notices when renewals change the key pair. HPKP is dead, but DANE/TLSA associations and mobile-app certificate pinning are very much alive — a renewal that rotated keys can break mail delivery from DANE-validating senders while every browser stays green. If TLSA records exist for the host, renewals and key changes must be coordinated with them, not just with the certificate calendar.

Above the handshake: the header layer

Some of what looks like TLS trouble lives one layer up. Missing ALPN quietly costs HTTP/2 and shows up as slowness, not errors. HSTS decides whether a downgraded first connection is possible at all — and its absence is a policy gap that no handshake probe flags as an error. Mixed-content warnings after an HTTPS migration are content references, not certificate problems. Read the response headers systematically with the HTTP Header Analyzer when the handshake itself checks out.

And when redirects are in play — HTTP to HTTPS, apex to www, old domain to new — walk the chain explicitly with the Redirect / Canonical / Indexability Checker: every hop is its own TLS endpoint with its own certificate, and the incident is often on hop two of a chain everyone forgot exists. A clean external diagnosis names the failing layer precisely — name, chain, protocol, or policy above it — and that single sentence is most of the fix.