Reading an SSL Certificate Field by Field: Subject, SAN, Validity and Extensions

A certificate is a small, highly structured document, and most support tickets about SSL collapse once someone actually reads it. Whether you paste a PEM file or fetch a live endpoint, decoding turns base64 noise into a handful of fields with precise meanings.

The fields that matter

• Subject: historically the identity of the certificate. For web certificates today the Common Name (CN) inside it is decorative — the authoritative name list lives in the SAN extension.
• Subject Alternative Name (SAN): every hostname the certificate covers, as dNSName entries. If a browser warns about a name mismatch, the answer is always in this list, not in the CN.
• Validity: notBefore and notAfter. Leaf certificates are capped at 398 days by CA/Browser Forum ballot, so expiries arrive annually and expire silently — the single most common production outage in this space.
• Issuer: the CA that signed it. Compare it with what you purchased; a “Let’s Encrypt” issuer on a paid order, or an unknown issuer name, is worth questioning.
• Serial number: unique per certificate per CA. This is what you quote when revoking, and what CAA/CT discussions revolve around.
• Signature algorithm: sha256WithRSAEncryption or ECDSA equivalents are fine; SHA-1 signatures are rejected by every modern client.
• Public key: algorithm (RSA or EC) and size — 2048-bit RSA or P-256 ECDSA are the current norms.

Extensions that change behaviour

Three extensions decide whether a certificate actually works for its job:

1. Key Usage: digitalSignature and keyEncipherment for typical TLS; if keyCertSign is missing you are not looking at a CA certificate no matter what the name says.
2. Extended Key Usage (EKU): serverAuth for serving TLS, clientAuth for mutual TLS. A certificate without serverAuth will be rejected by browsers even though everything else is valid — a common trap with internally generated certs.
3. Basic Constraints: CA:TRUE versus CA:FALSE. An intermediate must have CA:TRUE with a path length, or chains built through it fail.

From the shell, the same inspection is one command:

openssl x509 -in cert.pem -noout -text
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates -ext subjectAltName

Verifying what the CA issued

When something looks off — wrong names, short validity, an issuer you do not recognise — check the certificate against the public record: certificate transparency logs should contain an entry with the same serial number. Absence from CT means it was never publicly trusted; presence with a different serial means you are looking at a different, possibly fraudulent, certificate.

For a quick read without remembering openssl flags, paste the PEM into the certificate decoder and it lays out subject, SAN entries, validity window, key parameters and every extension in labelled form — the fastest way to answer “what did the CA actually issue and when does it die?”.