How to Read an SSL/TLS Certificate Chain
A TLS certificate is a signed statement binding a public key to an identity, typically a hostname, issued by a certificate authority (CA) that browsers and operating systems have agreed to trust. Understanding the chain behind that single certificate is what lets you actually diagnose a "not secure" warning instead of just seeing that one exists.
Last updated: August 29, 2026
Leaf, intermediate, and root certificates
The certificate a server presents (the leaf certificate) is signed by an intermediate CA certificate, which is in turn signed by a root CA certificate that ships pre-trusted in browsers and operating systems. A server needs to present the full chain, leaf plus intermediates, because a client generally only trusts the root directly. Skip an intermediate and most browsers will fail to build a trusted path even though the leaf certificate itself is perfectly valid.
What to actually check
- Expiry. How many days remain before the certificate stops validating.
- SAN coverage. The Subject Alternative Names list of every hostname the certificate is valid for; a mismatch here is what triggers a hostname-mismatch warning.
- Key type and size. RSA 2048-bit or ECDSA P-256 are current safe baselines; smaller/older key sizes are increasingly rejected or flagged.
- Chain completeness. Whether the server sent every intermediate certificate needed to build a path to a trusted root.
Why "certificate expired" errors happen
Every certificate in the chain has its own validity window, and if any one of them, leaf, intermediate, or root, has passed its expiry, verification fails. This is why a renewal sometimes still breaks things: the new leaf certificate might be issued under a different, unexpired intermediate that the server configuration wasn't updated to also serve.
Self-signed vs CA-issued vs broken-chain
A self-signed certificate is signed by its own private key rather than a recognized CA. That's fine for internal/testing use, but it will always show as untrusted to a normal browser since there's no path to a root it already trusts. A CA-issued certificate with a broken chain (missing intermediate) looks similar from the browser's point of view even though the certificate itself is legitimate. The fix there is server-side configuration, not a new certificate.
Connect directly to any host and port to see the full presented certificate chain, negotiated protocol/cipher, key strength, SAN coverage and expiry.
Frequently asked questions
What's the difference between a certificate and a private key?
The certificate is the public, signed statement binding a public key to a hostname. It's meant to be shared with anyone connecting. The private key is the secret half of that key pair used to prove the server actually controls the certificate; it must never be shared or exposed.
Why does my browser trust a certificate that a command-line tool flags as untrusted (or the reverse)?
Usually because of a missing intermediate certificate. Browsers sometimes cache intermediates they've seen before and can still build a trusted path even when the server didn't send one; a command-line tool checking cold, with no such cache, will correctly report the chain as incomplete.
How far in advance should I renew a certificate?
Most guidance suggests renewing with at least a couple of weeks of buffer before expiry, to leave room to catch and fix any issues with the new certificate before the old one actually stops working.
Is a bigger key always better?
Not really. Beyond the current safe baseline (RSA 2048-bit or ECDSA P-256), a larger key mostly adds computational overhead without a meaningful practical security gain, and can even be rejected by some systems for being non-standard.