What an X.509 certificate actually contains
An X.509 certificate is a signed data structure defined by RFC 5280, and it is really two things stapled together: a to-be-signed (TBS) body that holds the identity and key material, and a signature block where a Certificate Authority vouches for that body. The TBS body carries eight core fields — version, serial number, signature algorithm, issuer, validity period, subject, subject public key info, and (in version 3) a list of extensions. The signature block then repeats the algorithm identifier and stores the actual bytes the CA computed by hashing the TBS body and signing that hash with its private key. Everything a browser needs to decide "is this the right server, is the key trustworthy, and has it expired" lives in those fields.
That is the summary an AI Overview will give you. What it can't show you is how the fields fit together, which ones browsers actually enforce in 2026, and where each one goes wrong — so below is a labeled diagram of the real structure, a field-by-field reference table, and the modern gotchas (SAN vs CN, the 398-day limit, Basic Constraints) that decide whether a certificate is accepted or thrown out.
The anatomy of a certificate
Notice the split: the CA never signs the whole certificate, it signs a hash of the TBS body. When your browser validates the chain, it re-hashes that same body and checks the signature against the issuer's public key. Tamper with a single byte of the subject or the SAN list and the hash changes, the signature no longer verifies, and the connection is refused.
Field-by-field reference
| Field | What it holds | Why it matters / common gotcha |
|---|---|---|
| Version | v1, v2, or v3 (encoded 0, 1, 2) | Only v3 supports extensions. Every real TLS cert today is v3. |
| Serial Number | Unique positive integer per issuing CA | Used by CRL/OCSP to name revoked certs. Must be ≤20 octets and carry random entropy (anti-collision). |
| Signature Algorithm | e.g. sha256WithRSAEncryption, ecdsa-with-SHA256 | SHA-1 signatures are deprecated and rejected by browsers. |
| Issuer | Distinguished Name of the signing CA | Must exactly match the Subject of the CA one link up the chain. |
| Validity | Not Before and Not After timestamps (UTC) | Public TLS certs are capped at 398 days. Expiry is the #1 cause of outages. |
| Subject | Distinguished Name of the cert owner | CN inside the Subject is legacy — no longer used for hostname matching. |
| Subject Public Key Info | Algorithm + the public key bytes | RSA 2048+/ECDSA P-256+. This is the key the browser encrypts/verifies against. |
| Subject Alternative Name | List of DNS names, IPs, or emails | The field browsers actually match the hostname against. Wildcards (*.example.com) live here. |
| Basic Constraints | CA:TRUE/CA:FALSE (+ path length) | Stops a leaf cert from signing other certs. Critical extension. |
| Key Usage | Bit flags: digitalSignature, keyEncipherment, keyCertSign… | Restricts low-level operations the key is permitted to do. |
| Extended Key Usage | OIDs: serverAuth, clientAuth, codeSigning… | Missing serverAuth = browser rejects the TLS handshake. |
| AKI / SKI | Authority & Subject Key Identifiers | Hashes that let a verifier link a cert to the exact issuing key when building the chain. |
| AIA / CRL Dist. Points | URLs for OCSP and CA issuer / revocation lists | How clients fetch revocation status and missing intermediates. |
| SCTs | Signed Certificate Timestamps | Proof the cert was logged to Certificate Transparency; Chrome requires them. |
The three fields people get wrong
SAN, not CN. The single most common misconception is that the Common Name is the hostname. It was, historically — but since Chrome 58 (May 2017) and equivalent changes in Firefox and Safari, clients match the requested hostname only against the Subject Alternative Name list. If you request a cert with www.example.com in the CN but forget to include it in the SAN, every modern browser throws NET::ERR_CERT_COMMON_NAME_INVALID. When you deploy a cert, check the SAN list first — that is the authoritative name field.
The 398-day ceiling. Under the CA/Browser Forum Baseline Requirements, a publicly trusted TLS certificate issued on or after 1 September 2020 cannot be valid for more than 398 days. This is why automated renewal (ACME/Let's Encrypt) is now the norm rather than a convenience. Private and internal CAs are not bound by this limit, but any cert from a public CA will be rejected at issuance if you ask for longer. (The industry is moving toward even shorter lifetimes, so build automation now.)
Basic Constraints is a security boundary. CA:TRUE means a certificate is allowed to sign other certificates. On a leaf certificate this flag must be CA:FALSE (or absent). The infamous class of attacks where an end-entity cert was used to mint fraudulent certificates existed precisely because clients once ignored this flag. Today it is enforced: a leaf cert presenting CA:TRUE is a red flag, and a properly built chain checks it at every link.
Read a certificate yourself
You never have to trust a description — decode the certificate and read the fields directly. Paste the PEM block into our client-side X.509 decoder, which expands the DER structure entirely in your browser so the certificate never leaves your device. Or run it locally:
openssl x509 -in cert.pem -noout -text
Both expand every field — version, serial, issuer, subject, validity, public key, and each extension. Before you trust or deploy a certificate, confirm three things: the SAN list contains the exact hostname you are serving, Not After is comfortably in the future, and the Extended Key Usage includes serverAuth. Those three checks catch the overwhelming majority of certificate failures.