When your browser shows the lock, it's confirming that a certificate authority the operating system already trusts has cryptographically vouched that the public key on this connection belongs to the domain in the address bar — nothing more. A certificate is exactly that vouching document: it binds a public key to a set of names, signed by an issuer whose own key traces up to a root your OS shipped with. It does not vouch that the site is honest, well-run, or free of an SQL injection. Plenty of phishing pages have valid certificates.
So when a cert "breaks," the failure is almost always in one of four fields, and knowing which one turns a red browser screen into a five-minute fix.
The four fields that actually matter
| Field | What it is | What breaks when it's wrong |
|---|---|---|
| Subject Alternative Name (SAN) | The list of DNS names the cert is valid for | NET::ERR_CERT_COMMON_NAME_INVALID — you're serving www. on a cert that only lists the apex |
| Issuer / chain | The CA that signed it, up to a trusted root | unable to get local issuer certificate — you deployed the leaf but forgot the intermediate |
| Not Before / Not After | The validity window | NET::ERR_CERT_DATE_INVALID — expired, or the server clock is wrong |
| Public key | The key the handshake authenticates against | Handshake fails if the served key doesn't match the private key on disk |
Note that the Common Name (CN) isn't in that list. Modern browsers stopped reading CN for hostname matching years ago — Chrome since 58 (2017) requires the name in the SAN. A cert with the right CN and a missing SAN still throws ERR_CERT_COMMON_NAME_INVALID.
SSL vs TLS — same job, different decade
"SSL certificate" is the term everyone still uses, but SSL itself is dead: SSL 3.0 was broken by POODLE in 2014, and TLS 1.0/1.1 were deprecated in 2021 (RFC 8996). Every current connection is TLS 1.2 or 1.3. The certificate format didn't change with the rename — an "SSL cert" and a "TLS cert" are the same X.509 file — so the word persists harmlessly. Just don't let it fool you into leaving old protocol versions enabled on the server; that's the part that actually matters for security.
Check the chain the server is actually sending, not the file you meant to install.
openssl s_client -connect example.com:443 -servername example.comshows the real served chain from the outside — the single most common production cert bug is a leaf certificate deployed without its intermediate, which works in your browser (it cached the intermediate from another site) and fails for a fresh client withunable to get local issuer certificate.
The expiry field is the one that pages you at 2am, so automate renewal and alert on days-remaining, not on the outage. When something does break, decode the served cert — a certificate decoder will lay out the SANs, issuer, and validity window so you can see which of the four fields is lying to you.
Cover photo by Stanislav Kondratiev on Pexels.