TLS errors are some of the most alarming a browser can show, yet the underlying certificate is a surprisingly readable document. Once you know which fields matter and how the chain is supposed to line up, most “secure connection” problems become a five-minute inspection rather than a mystery.
The chain is a linked list
A TLS handshake delivers not one certificate but a chain: your server (leaf) certificate, followed by one or more intermediates, each signed by the one above it, ending at a root that the client already trusts. The server is supposed to send the leaf and the intermediates — not the root, because the client has its own copy.
The most common deployment mistake is sending an incomplete chain: the leaf alone, without the intermediate that links it to a trusted root. Browsers that have seen that intermediate before may still work, which masks the problem; a fresh client or a strict validator fails. Always check that your server sends every certificate needed to reach a root, except the root itself.
SANs, not the Common Name
The hostname check is done against the Subject Alternative Name (SAN) extension, not the Common Name field. A certificate is valid for a hostname only if that hostname appears in its SAN list. Wildcard SANs (*.example.org) cover one level of subdomain; they do not match example.org itself or a.b.example.org.
When a site works in one browser but not another, or works for www but not the apex, the SAN list is the first thing to check. A certificate monitor that lists every SAN and the days remaining for each makes this trivial.
Expiry sneaks up
Certificates expire, and expired certificates are rejected outright regardless of how valid the rest of the chain is. The notAfter field is the hard deadline. The practical problem is that expiry is easy to forget between renewals — set a monitor that reports days remaining for every SAN so you get a warning at 30, 14, and 7 days rather than at zero.
Also note the notBefore: a certificate is not valid before its start date either. This bites people who install a renewed certificate ahead of its validity window and wonder why it is rejected.
The trust anchor
Ultimately the chain is only as good as the root it terminates in. Clients trust a curated set of root certificates maintained by their operating system or browser. A chain that ends in a private root will fail on every client that does not have that root installed — fine for internal services, a disaster for public ones.
Run an SSL/TLS check that reports the full chain, each certificate’s issuer and subject, the SAN list, the protocols and ciphers negotiated, and the days to expiry. With those fields in front of you, almost every TLS error resolves to one of: incomplete chain, missing SAN, expired certificate, or untrusted root — and each has an obvious fix.