X.509 Certificates Explained: Fields, Extensions, and Structure

What an X.509 certificate is

A public key on its own proves nothing. Anyone can generate a key pair and claim to be your bank — the hard part is proving that a particular public key really belongs to a particular identity. An X.509 certificate solves that by being a signed statement: a certificate authority (CA) inspects who you are, then issues a document that says "this public key belongs to this subject," and signs it with the CA's own private key. Because browsers and operating systems already trust the CA's key, they can extend that trust to anything the CA signs.

That trust model is the foundation of public key infrastructure (PKI), and X.509 is the certificate format PKI is built on. The same structure is used whether the certificate authenticates a website over TLS, a software publisher through code signing, or a person via S/MIME email. What changes between those uses isn't the format — it's which fields and extensions are filled in.

The X.509 standard and RFC 5280

"X.509" is the name of an ITU-T recommendation that first defined a public-key certificate format back in 1988. It has gone through three versions. Version 1 had only a fixed set of fields; version 2 added issuer and subject unique identifiers; and version 3, finalized in the mid-1990s, added the flexible extensions mechanism that all modern certificates rely on. In practice, essentially every certificate you'll encounter today is X.509 v3.

The base ITU-T standard is broad, so for the public internet the IETF narrowed it into a concrete profile: RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and CRL Profile." RFC 5280 spells out exactly which fields and extensions a certificate must contain, how they're encoded, and which extensions a conforming client must understand — among them key usage, certificate policies, subject alternative name, basic constraints, name constraints, policy constraints, extended key usage, and inhibit-anyPolicy. On top of RFC 5280, the CA/Browser Forum Baseline Requirements add further rules that publicly trusted CAs must follow, which is why a browser-trusted certificate is more tightly constrained than the raw standard allows.

The three-part structure

At the top level, an X.509 certificate is a sequence of just three elements. Understanding this split makes everything else fall into place:

Notice that the signature is over the body, not over itself — the CA signs the tbsCertificate and then appends the signature. This is exactly why a chain works: each certificate's body is signed by the key in the certificate above it, up to a trusted root. Our guide to the SSL certificate chain walks through how those signatures link together.

The core fields, one by one

Inside the body, these are the fields you'll see in any certificate viewer or OpenSSL dump:

The Subject and Issuer are both written as a Distinguished Name (DN) — an ordered set of attributes such as CN (common name), O (organization), OU (organizational unit), and C (country). The richness of the Subject DN is what distinguishes validation levels: a DV certificate carries little beyond the hostname, while OV and EV certificates include verified organization details. Our certificate types guide covers what each level puts in the Subject.

X.509 v3 extensions: where the real work happens

The fixed fields above can't express everything a modern certificate needs to say, so version 3 added extensions: optional, typed fields, each identified by an object identifier (OID). Every extension carries a critical flag — if an extension is marked critical and the client doesn't understand it, the client must reject the certificate rather than ignore the field. These are the extensions that matter for web certificates:

SAN vs Common Name: why CN no longer matches the hostname

For years, the hostname lived in the Common Name (CN) attribute of the Subject DN, and clients matched it against the site you were visiting. That worked, but it was a hack: CN is a single free-text field with no type, so it couldn't cleanly express multiple names or distinguish a hostname from a person's name. Both the IETF and the CA/Browser Forum deprecated using CN for hostname matching in favor of the typed, multi-valued Subject Alternative Name extension.

The practical takeaway when you generate a request: make sure every name you need is in the SAN. When you create a certificate signing request (CSR), list all hostnames as SAN entries rather than relying on the Common Name — the CA copies those into the issued certificate's SAN extension. How many names you can put there is a product question rather than a format one: a single-name certificate carries one, a wildcard covers one level of subdomains, and a multi-domain certificate holds a list. The SSL certificate range sets out which coverage each type gives you before you write the CSR.

What does a public CA have to add in 2026?

RFC 5280 describes what an X.509 certificate may contain, and it is permissive: extensions are optional, validity has no ceiling, and nothing forces a Subject Alternative Name. A publicly trusted certificate lives under a second, stricter rulebook — the CA/Browser Forum Baseline Requirements — and that is the one browsers actually enforce. This gap is why a certificate can be flawless X.509 and still be refused by every browser on the internet.

As of August 2026, four requirements shape what you will see when you dump a certificate from a public CA. A SAN is mandatory, and has been since 2012. The notAfter date can sit at most 200 days after issuance, the first step of a schedule that drops the maximum to 100 days on 15 March 2027 and 47 days on 15 March 2029 — our guide to the certificate lifetime changes covers the full timeline. The Extended Key Usage must name serverAuth, which is the field that makes it a TLS certificate rather than a code-signing one.

The fourth is the one most field-by-field explainers still omit. Open a current certificate and you will find an extension holding embedded Signed Certificate Timestamps — receipts proving the certificate was published to public Certificate Transparency logs before it was issued. Chrome wants at least two SCTs from distinct logs when a certificate's lifetime is 180 days or less, and three when it is longer. A certificate without them is treated as untrusted no matter how good its signature is, so in practice the CT extension is now as load-bearing as the SAN.

How to read a certificate yourself

Everything above is visible with one command. To decode a certificate file into human-readable form, point OpenSSL at it:

That prints the version, serial number, signature algorithm, issuer, validity dates, subject, public key, and every extension — including the full SAN list. To inspect what a live server is actually serving, connect to it directly:

Your browser shows the same structure through the padlock menu, and so do online checkers. For the complete set of inspection and conversion commands, keep our OpenSSL commands cheat sheet handy — it covers reading, verifying, and converting certificates between formats.

How an X.509 certificate is stored on disk

One last point of confusion worth clearing up: the X.509 structure and the file format it's saved in are two different things. The logical structure is always encoded with a scheme called DER (Distinguished Encoding Rules), which turns the fields into a precise binary form. What changes is the container around that binary:

• PEM wraps the DER bytes in Base64 text between -----BEGIN CERTIFICATE----- markers — the most common format on Linux servers.
• DER stores the raw binary directly, common in Java and Windows contexts.
• PKCS#12 (PFX) bundles the certificate, its chain, and the private key together in one password-protected file.

The certificate inside is the same X.509 v3 object in every case — only the packaging differs. Our certificate file formats guide goes deep on PEM, DER, PFX, and P7B and shows how to convert between them. And if you're still deciding which certificate to request in the first place, our walkthrough on which SSL certificate you need maps validation levels and coverage to real use cases.