Guide
How to read an SSL certificate
A certificate check returns a dozen fields. Four of them decide whether the certificate works, and the rest explain why when it does not.
A TLS certificate makes one claim: that the holder controls a particular name, attested by an authority the browser already trusts. Everything in the certificate exists to support or qualify that claim, and reading one is mostly a matter of knowing which fields carry weight.
Subject — what the certificate is for
The subject identifies the entity. The part that matters is the common name (CN), historically the hostname the certificate covers.
Historically, because modern browsers ignore the CN for hostname matching entirely.
They use the subject alternative names instead. A certificate whose CN says
example.com but whose SAN list omits it will be rejected, which is a genuinely confusing
failure the first time you meet it.
Subject alternative names — what it actually covers
The SAN list is the authoritative set of names. A certificate is valid for a hostname if and only if that name appears here.
- Exact names —
example.comandwww.example.comare different entries. Covering both means listing both. - Wildcards —
*.example.commatcheswww.example.comandapi.example.com, but notexample.comitself, and nota.b.example.com. A wildcard spans exactly one label.
The commonest mismatch is a certificate for *.example.com served on the root domain.
Both names need to be present.
Issuer and the chain
The issuer names the authority that signed the certificate. Almost never is that a root directly: authorities keep roots offline and sign through intermediates, so a real chain looks like
your certificate → intermediate CA → root CA (in the browser's trust store) The server must send the intermediates. Only the root is already on the client. Omitting them is the single most common certificate misconfiguration, and its signature symptom is a site that works in your browser and fails everywhere else — because your browser cached the intermediate from some other site and is quietly filling the gap.
This is why a checker reports the chain length. A chain of one means only the leaf was sent, and clients without a cached intermediate will fail.
Validity dates
Not before and Not after bound the period the certificate may be trusted.
Outside it, clients refuse regardless of everything else being correct.
Public certificates are now issued for months rather than years, which makes automated renewal
effectively mandatory — and makes silent renewal failure the thing to watch for. A
not before date in the future is rarer and usually means clock skew on the server rather
than a certificate problem.
Fingerprints
A fingerprint is a hash of the whole certificate — a short identifier for an exact certificate, used to confirm two parties are looking at the same one. SHA-256 is the meaningful one; SHA-1 fingerprints are still shown for compatibility but SHA-1 itself is no longer collision-resistant and should not be relied on for identity.
Why a certificate is called untrusted
Validation fails for a small number of distinct reasons, and the distinction matters:
| Result | What it means |
|---|---|
| Expired |
Past not after. Renewal has failed, often silently.
|
| Hostname mismatch | The name is not in the SAN list. Often a wildcard on a root domain. |
| Self-signed | No authority vouches for it. Fine internally, not for the public web. |
| Incomplete chain | Intermediates were not sent. Works in some clients, fails in others. |
| Unknown issuer | The root is not in the client's trust store. |
Why a checker inspects an invalid certificate anyway
A browser stops at the warning. That is right for browsing and useless for diagnosis: the certificate you most need to read is the broken one.
IPGet's SSL certificate checker therefore completes the handshake without requiring validation to succeed, then reports the outcome — expired, mismatched, untrusted — alongside the issuer, chain and SAN list. Validation still runs; it simply decides what to tell you rather than whether to speak at all.
What a valid certificate does not tell you
It confirms control of a name and encrypts the connection. It does not mean the site is trustworthy, well run, or free of malware — anyone can obtain a certificate for a domain they control, phishing sites included. The padlock has never meant "safe"; it means "encrypted to the holder of this name".
For how a site instructs browsers to require that encryption, see HTTP security headers — HSTS is the header that closes the plaintext first request, and the HTTP headers checker shows whether a site sends it.
Frequently asked questions
What is the difference between SSL and TLS?
TLS is the protocol; SSL is its obsolete predecessor. Every version of SSL is broken and disabled, and what people call an "SSL certificate" is a TLS certificate. The name persists out of habit, and this guide uses it the way people search for it.
Why does a certificate work in my browser but fail a checker?
Almost always an incomplete chain. Browsers cache intermediate certificates from other sites they have visited, so one that has already seen your intermediate can validate your site while a fresh client cannot. Serving the full chain fixes it; testing from a browser that has already cached it will not reveal it.
Does an expired certificate mean the connection is insecure?
The encryption still works — expiry does not weaken the cipher. What lapses is the assurance: nobody has re-verified that the holder still controls the name, and a revoked or transferred domain would not be caught. Browsers refuse it because that assurance is the point of the certificate.
Do I need to check my certificate if it renews automatically?
Occasionally, yes. Automated renewal fails quietly more often than people expect — a changed validation path, an expired account key, a firewall rule blocking the challenge. Checking from outside your own network is the only way to see what visitors actually get.
Try it yourself
Everything above is easier to follow against a real answer.