All posts
May 30, 20266 min read

How to read an SSL certificate: subject, SAN, chain, and expiry

When a browser shows the padlock, it has just read and verified a certificate you can read too. A TLS (still commonly called SSL) certificate is a structured document that answers three questions: who is this, who vouches for them, and how long is it valid. Knowing the fields turns "the certificate is broken" into a specific, fixable diagnosis.

The fields that matter

  • Subject — the entity the certificate is issued to. The historic Common Name (CN) field held the hostname, but browsers no longer trust it.
  • Subject Alternative Name (SAN) — the list of hostnames the certificate actually covers. This is the field that counts now. If the name in the address bar is not in the SAN list, the browser rejects it, even if the CN matches. A certificate for example.com that omits www.example.com from its SAN will fail on the www host.
  • Issuer — the certificate authority that signed it.
  • Validity (Not Before / Not After) — the window during which the certificate is valid. Expiry is the single most common production outage of the bunch.
  • Serial number and fingerprint — unique identifiers, useful for pinning and for matching a certificate to its private key.

Pull all of these for any host with the SSL Checker, or paste a PEM certificate into the SSL Decoder to read one you already have.

The chain of trust

Your server certificate is not trusted on its own. It is signed by an intermediate certificate, which is signed by a root that browsers already trust. The browser walks this chain from your certificate up to a known root. The classic failure is a missing intermediate: the certificate is valid, but your server did not send the intermediate alongside it, so some clients cannot complete the chain. Desktop browsers sometimes paper over this with cached intermediates while mobile clients fail, which makes it maddening to reproduce. The fix is to install the full chain on the server, not just the leaf.

The problems to catch early

  • Expiry. Set a reminder well before Not After, or automate renewal. A lapsed certificate takes the whole site down with a scary warning.
  • Name mismatch. Verify the exact hostname is in the SAN, including or excluding www as your site requires.
  • Incomplete chain. Test from a clean client, not just your own browser.
  • Wrong key. A certificate must match the private key it was issued for. If they do not pair, TLS will not start.

You can verify the certificate and key belong together with the Key Matcher, confirm the issuing chain with the CA Matcher, and check that a certificate was logged publicly with the CT Log Lookup. For revocation status, the OCSP Checker tells you whether a CA has pulled a certificate before its expiry. Run the SSL Checker first; it surfaces most of these in one pass.