Skip to content

← All writing

How to Read a TLS Certificate (and Spot a Bad One)

· by Andergrove Software

A TLS certificate looks like an opaque blob of Base64, but it is really just signed metadata: a statement that a particular public key belongs to a particular name, vouched for by a certificate authority (CA). Once you can read the handful of fields that matter, a certificate stops being a black box you either trust or don't, and becomes something you can actually check.

You can pull any certificate apart as you read in the certificate decoder — it parses the PEM entirely in your browser, so it is safe to inspect a production certificate without sending it anywhere.

What a certificate actually proves

A certificate binds a public key to an identity (a hostname), and a CA signs that binding with its own private key. When your browser connects to a site over HTTPS, the server presents its certificate; the browser checks that a CA it trusts signed it, that the name matches the site, and that it has not expired. If all three hold, the browser trusts the public key inside and uses it to set up the encrypted connection.

Crucially, the certificate proves identity, not safety. A valid certificate means "you are really talking to example.com," not "example.com is trustworthy." Phishing sites get valid certificates all the time — the padlock means the connection is private, nothing more.

The fields that matter

Decode a certificate and you will see a lot of fields. These are the ones worth reading:

  • Subject. Who the certificate is for. Historically the important part was the Common Name (CN), but modern browsers ignore the CN for hostname matching and use the SAN instead. For domain-validated certificates the subject is often just the CN and nothing else.
  • Subject Alternative Name (SAN). The list of hostnames the certificate is valid for — example.com, www.example.com, maybe a wildcard *.example.com. This is the field browsers actually check. If the hostname you visited is not in the SAN, the certificate is rejected, even if the CN matches. A missing www entry is a classic cause of "your connection is not private."
  • Issuer. The CA that signed the certificate. For a real public certificate this is an organisation like Let's Encrypt, DigiCert or Google Trust Services. If the issuer equals the subject, the certificate is self-signed.
  • Validity (notBefore / notAfter). The window the certificate is valid for. Public certificates are now capped at around a year (and heading shorter), so a multi-year validity is a sign of an internal or legacy certificate.
  • Public key. The algorithm and size — RSA 2048/4096, or an elliptic-curve key on P-256/384. A 1024-bit RSA key is obsolete and rejected.
  • Signature algorithm. How the CA signed the certificate, e.g. sha256WithRSAEncryption. Anything using SHA-1 is a red flag. The signature is computed over a hash of the certificate — the same SHA-256 you meet everywhere.
  • Key usage / extended key usage (EKU). What the key is allowed to do. A server certificate should list serverAuth; a certificate presented for the wrong purpose is suspicious.

The chain of trust

Your browser does not trust every certificate directly. It ships with a set of root CA certificates, and everything else is trusted by a chain: the server's leaf certificate is signed by an intermediate CA, which is signed (directly or through more intermediates) by a root the browser already trusts. The browser walks that chain up to a trusted root; if it can, the leaf is trusted.

This is why a certificate can be perfectly valid and still fail: if the server does not send the intermediate certificate, some clients cannot complete the chain to a trusted root and reject the connection — even though desktop browsers, which cache common intermediates, may accept it. An incomplete chain is one of the most common "works on my machine" TLS bugs. The fix is to configure the server to serve the full chain (leaf + intermediates), not just the leaf.

Red flags to check

When you decode a certificate, these are the things that should make you stop:

  • Expired (or not yet valid). Check notAfter against today. An expired certificate is the single most common outage cause — automate renewal.
  • Hostname mismatch. The name you connected to is not in the SAN list. Either the wrong certificate is installed, or something is intercepting the connection.
  • Self-signed. Issuer equals subject and no trusted CA vouches for it. Fine for a local dev box you explicitly trust; a red flag on anything public, because anyone can mint one for any name.
  • Weak signature (SHA-1). SHA-1 is broken for collision resistance and has been distrusted by browsers since 2017. A public certificate signed with SHA-1 should not exist today; treat one as compromised or ancient.
  • Weak key. RSA below 2048 bits, or unusual/unknown curves. Reject.
  • Suspicious issuer. A CA you have never heard of on a certificate that claims to be a major site, or a mismatch between the brand and the issuer, is worth a second look.

None of these require special tools — every one of them is visible in the decoded certificate.

PEM vs. DER, and inspecting safely

Certificates travel in two encodings. PEM is the Base64 text form wrapped in -----BEGIN CERTIFICATE----- / -----END CERTIFICATE-----; it is what you paste into most tools and what web servers usually read. DER is the raw binary form of the same data (common on Windows and in Java keystores, often as .cer or .der files). They are interchangeable — PEM is just Base64-encoded DER with a header.

Because a certificate contains only public information (the public key and the identity, never the private key), it is safe to inspect. The risk with online decoders is not the certificate itself but the habit: paste a private key into the wrong "SSL checker" and you have leaked it. Prefer a tool that runs locally. The Andergrove certificate decoder parses everything in your browser and never uploads it, and the certificate-to-CSR generator can rebuild a matching signing request when it is time to renew. For how the same signatures protect tokens rather than connections, see JWT security — RS256 uses exactly the RSA signing described here.

The short version

A certificate is signed metadata binding a key to a name. Read the SAN (not the CN) to see what it covers, the issuer to see who vouches for it, the validity to see if it is current, and the signature algorithm to see if it is modern. Check the chain is complete. If any of expiry, hostname, or self-signed is wrong, do not trust it — and now you can tell, instead of guessing.

Decode a certificate →