How to check an SSL/TLS certificate (and what to look for)
Every HTTPS site relies on a TLS certificate. Here's how to read one, what each field actually means, and the things that should make you suspicious.
Every time your browser shows a padlock, it's because the server presented a valid TLS certificate. Most IT folks know how to install one — far fewer know how to read one. This post walks through what every field means and the red flags you should know.
The fields that actually matter
A TLS certificate has dozens of fields, but only a handful drive real-world trust:
- Subject CN — the hostname the certificate was issued for. Should match the URL you're hitting.
- Subject Alternative Names (SANs) — modern browsers ignore CN and use the SAN list. Almost every real cert covers multiple hostnames here.
- Issuer — the CA that signed this cert. If the issuer is yourself, the cert is self-signed (only OK for internal services).
- Validity window — Not Before / Not After. Anything more than 398 days from a public CA is non-compliant; clients will reject it.
- Signature algorithm — should be SHA-256 or stronger. SHA-1 certs have been rejected by major browsers since 2017.
- Public key — RSA 2048+ or EC 256+. Anything smaller (RSA 1024, for example) is considered weak.
How to actually look one up
From a shell, the canonical command is openssl s_client:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -text -nooutThat works, but the output is verbose and you'd have to paste it into a parser to extract the bits you care about. Our SSL/TLS Certificate Checker does the same handshake server-side and lays out the important fields on one page — including the chain of intermediates and the SHA-256 fingerprint.
Things that should make you suspicious
- CN doesn't match the URL — type
example.cominto the address bar and get a cert for*.example.org. Probably an error. Could be a misconfiguration or a man-in-the-middle. - Self-signed on a public site — your browser would warn you; if you see this in a cert dump from a site you trust, something's wrong.
- Very long validity — public CAs are limited to 398 days. A 5-year cert means it was issued by someone's internal CA, or the issuer is misconfigured.
- Weak signature algorithm — anything with
sha1ormd5is broken. - Missing SANs — modern browsers refuse to honor a cert that only has a CN. You'll get a NET::ERR_CERT_COMMON_NAME_INVALID error.
Why the chain matters
Your browser doesn't trust the leaf cert directly — it trusts the root CA in its trust store, and then walks up the chain (leaf → intermediate(s) → root). If any link in that chain is missing, expired, or untrusted, the connection fails. Always check the intermediates alongside the leaf — that's what most cert tools skip, and it's where most TLS bugs live.
Try it on your own domain, or anyone else's, with our SSL/TLS Certificate Checker. Paste a hostname, get the full report.
Keep reading
- How to read an open port (and when to actually worry)An 'open port' isn't a vulnerability by itself — it's information. Here's how to tell whether a port being open is fine, suspicious, or actively dangerous, and what to do about each case.
- DMARC, SPF, and DKIM explained (and why you need all three)Email spoofing is trivially easy without email authentication. Here's how SPF, DKIM, and DMARC work together — and how to check yours.