If you want the higher-level “what is SSL” or “what is TLS” framing, that is a separate page: What is SSL and SSL vs TLS. This one is the structural reference for the certificate file itself.

01What X.509 actually is

X.509 is an ITU-T standard, first published in 1988, that defines the format for public-key certificates. The version of it that the modern internet runs on is X.509 v3, profiled by the IETF in RFC 5280. RFC 5280 is the document you actually want when you need to know what a field means; the original ITU specification is denser and the IETF profile narrows it to what is used on the public web.

An X.509 certificate is a binary structure encoded in DER (Distinguished Encoding Rules), a deterministic subset of ASN.1. When you see a cert in PEM form (base64 between BEGIN/END markers), the bytes between those markers decode to DER, which decodes to the X.509 structure. PEM and DER are encoding choices; X.509 is the underlying schema. The PEM format itself is profiled in RFC 7468.

The same X.509 format is used for TLS server certificates, code-signing certificates, S/MIME, smartcards, IPSec peer auth, and most other places where a CA signs an identity assertion. The fields differ by use case (a code-signing cert has different extensions than a TLS server cert), but the outer structure is the same.

02The structure of a v3 certificate

An X.509 v3 certificate has three top-level pieces, in this order:

• tbsCertificate. “To be signed.” This is the actual certificate data: version, serial, validity, subject, public key, extensions. Everything you would call the “content” of the cert.
• signatureAlgorithm. The OID identifying the algorithm the CA used to sign the tbsCertificate.
• signature. The actual bytes of the CA’s signature over the tbsCertificate.

The CA signs only the tbsCertificate, not the whole document. When a client validates the cert, it re-hashes the tbsCertificate bytes and verifies the signature against the issuer’s public key. This is why a single byte changed anywhere inside tbsCertificate invalidates the whole cert – there is no per-field signature.

Inside tbsCertificate, the fields you will actually see in production are:

• version. Always v3 (encoded as integer 2) for any cert issued in the last fifteen years. v1 and v2 are historical.
• serialNumber. A positive integer chosen by the CA, unique within that CA. Per RFC 5280 it must contain at least 64 bits of unpredictable entropy as of 2016 (BR ballot 164). If the cert was issued recently, the serial will look like a 20-byte random number, not a sequence counter.
• signature (inside tbsCertificate). Same OID as the outer signatureAlgorithm. Yes, it is duplicated. The duplication is intentional – it lets the client verify the algorithm was not substituted by an attacker. Whatever, this field is rarely interesting.
• issuer. Distinguished name of the CA that signed this cert. Matches the subject of the issuing intermediate.
• validity. notBefore + notAfter, both in UTCTime or GeneralizedTime. The cert is invalid outside this window. Browsers enforce this strictly with no clock-skew grace.
• subject. Distinguished name of the entity the cert identifies. For TLS server certs the subject CN historically held the hostname, but Chrome and Firefox have ignored CN since 2017 – only the SAN extension counts now.
• subjectPublicKeyInfo. The public key plus its algorithm OID and parameters. RSA, ECDSA P-256, ECDSA P-384, or Ed25519 in 2026; everything else is legacy.
• extensions. The interesting part – see the next section.

03The extensions that actually matter

X.509 v3 introduced extensions so the CA can attach metadata to the cert without modifying the schema. Each extension is identified by an OID, marked critical or non-critical, and contains a DER-encoded value. RFC 5280 §4.2 catalogues the standard ones; CAs use a subset, plus a few non-standard ones from the CA/Browser Forum.

The extensions you will see on every public TLS server cert in 2026:

• Subject Alternative Name (SAN). The hostnames the cert is valid for. If the cert is for example.com and www.example.com, both go in the SAN. As mentioned above, this is the only place modern browsers look – the subject CN is decorative now. SANs can be DNS names, IP addresses, email addresses, or URIs depending on the cert type.
• Basic Constraints. Says whether this cert is a CA (and thus allowed to sign other certs) or an end-entity cert. On a leaf TLS cert this is set to CA: FALSE. On an intermediate it is CA: TRUE with a path-length constraint.
• Key Usage. Bit-flags for which cryptographic operations the public key in this cert may be used for. For a TLS server cert: digitalSignature + keyEncipherment (for RSA) or digitalSignature + keyAgreement (for ECDSA).
• Extended Key Usage (EKU). OIDs for which application contexts the cert is valid in. serverAuth for TLS server, clientAuth for TLS client, codeSigning for code-signing, emailProtection for S/MIME, etc. A cert with only serverAuth in EKU cannot be used to sign code, even if the key would technically allow it.
• Authority Information Access (AIA). Two pointers: where to fetch the issuer’s certificate (caIssuers, used by clients that need to chase the chain) and where to query OCSP for revocation status. Some servers serve only the leaf and rely on AIA caIssuers for the client to fetch the intermediate. This is a mistake – see the chain-of-trust section.
• CRL Distribution Points. The URL where the CA publishes its revocation list. Mostly vestigial in 2026 – OCSP and the CRLite scheme have largely replaced CRL fetches in modern browsers, but the field is still populated.
• Subject Key Identifier and Authority Key Identifier. Hashes of the subject’s and issuer’s public keys, used during chain construction to disambiguate which intermediate signed which leaf when the same CA has multiple active intermediates with the same name.
• Certificate Transparency SCTs. Signed timestamps from public CT logs, embedded in the cert at issuance time. As of 2018, browsers will not accept a public-web TLS cert that does not have at least two SCTs from logs they trust. The CT machinery is documented separately at the Certificate Transparency project.

Critical extensions are the ones a client must understand or it must reject the cert. Non-critical extensions can be ignored. Most extensions on a public TLS cert are non-critical; the ones marked critical are typically Basic Constraints, Key Usage, and (sometimes) Name Constraints on intermediates.

04How chains validate

Validating an X.509 cert against a trust anchor is a recursive walk:

1. Take the leaf. Verify its signature against the issuer’s public key. The issuer is whichever cert in the bundle has a subject DN matching the leaf’s issuer DN, with the matching Subject Key Identifier.
2. Take that intermediate. Verify its signature against its own issuer. Repeat.
3. Stop when you reach a self-signed cert that is in the client’s trust store. That cert is the trust anchor. Its signature is checked against itself, but the trust comes from being on the local list, not from any cryptographic check.

At each step the client also checks: is the cert within its validity window, is the signature algorithm one the client supports, are the critical extensions all understood, does the issuer’s Basic Constraints allow it to sign sub-certs, is the path length within the constraint, and (for the leaf) does the SAN cover the hostname being connected to. Any single failure rejects the whole chain.

The detailed rules are in RFC 5280 §6. The pseudo-code there is exhaustive but readable; if you ever need to debug a chain failure that “should work,” that section is where you start.

For a worked example of how a real CA structures its hierarchy and what goes wrong when the chain is wrong, see chained root vs single root. That page is the operational debugging story; this one is the structural reference.

05Reading a cert by hand

Three commands cover most diagnostic needs. Run any of these against a PEM-encoded cert file and you will get human-readable output of every field discussed above.

openssl x509 -in cert.pem -noout -text

That dumps the whole tbsCertificate in a verbose form. Pipe it through less on real production certs, the output runs to a hundred lines. To get just the parts you care about:

openssl x509 -in cert.pem -noout -subject -issuer -dates -ext subjectAltName,extendedKeyUsage,basicConstraints

To pull a cert off a live server (for diagnosing what is actually being served, as opposed to what is in your config files):

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null \
  | openssl x509 -noout -text

For a paste-and-read view in the browser, the SSL certificate decoder covers the same fields without leaving the page. For raw ASN.1 inspection (when even openssl is hiding something), Lapo Luchini’s asn1js is the standard tool.

06The fields that bite in production

Most chain-validation failures in production trace back to one of four things:

• Missing intermediate. Server is configured to serve only the leaf, not the bundle. Clients that have not seen this intermediate before fail. Symptoms: validates from your machine but not the customer’s. Fix: install fullchain.pem instead of cert.pem.
• Expired intermediate. The CA rotated its intermediate, you are still serving the old bundle. Symptom: works fine for years, then suddenly does not. Fix: pull the current bundle from the CA portal, redeploy.
• Hostname mismatch. Cert was issued for example.com only, request hits www.example.com. Modern CAs will let you issue with both in the SAN, but only if you request both at issuance time.
• Clock skew at issuance. Cert’s notBefore is twelve hours in the future because the CA’s clock was right and yours is wrong. Symptom: cert “is not yet valid” on a freshly issued cert. Fix: NTP. Always NTP.

None of these are X.509 problems strictly speaking – they are operational problems with how the cert is deployed. But all of them surface as cryptic validation errors, and knowing what fields actually exist makes the error messages legible.

07What does and does not need to change

X.509 v3 is, structurally, the same format it has been for twenty years. RFC 5280 has had errata but no major revisions. The things that have changed in 2026:

• Validity periods are getting much shorter. The CA/B Forum’s SC-081v3 ballot is stepping max validity down to 47 days through 2027. By the time it lands, every public TLS cert will be issued for under two months. The cert format is unchanged; the operational implication is that manual issuance is no longer viable.
• Crypto agility. RSA-2048 is being phased toward RSA-3072 / ECDSA P-256 floors. Ed25519 is allowed for some use cases but still rare on public TLS. Post-quantum hybrid certs are in late-stage standardisation; you will probably see them in production by 2027-2028.
• Certificate Transparency is universally required. Every public-web cert must appear in two CT logs before a browser will accept it. The SCT extension is now de facto mandatory. Look up any of your own certs at crt.sh to see your CT footprint.
• OCSP stapling is preferred over OCSP fetches. Live OCSP queries from the client to the CA are increasingly disabled by default in browsers (privacy + reliability concerns). Stapling – server fetches OCSP, attaches it to the handshake – is the modern path.

None of that breaks the X.509 format. It changes which fields you populate and how often you re-issue. The wire format, the ASN.1 structure, the way a chain validates: all of that is the same as it was in 2010.

08Working notes for 2026

Three things that are worth doing once on every fleet:

• Inventory every cert by hostname, issuer, and notAfter. The tooling for this is good now (Cert-Manager in k8s, Vault PKI, Smallstep, AWS ACM all expose inventories). The classic outage is the cert nobody knew existed, on a hostname nobody owned, expiring on a Saturday morning.
• Audit your chain bundle. Once a quarter, run openssl s_client against your public hostnames and confirm the chain that comes back includes the current intermediate. If your CA has rotated and you have not refreshed your bundle, this is how you find out.
• Pull NIST SP 800-57 part 1 once. The current revision is at NIST SP 800-57 Part 1 Rev 5. It covers key sizes and lifetimes for every common algorithm. You do not need to read it cover to cover, but knowing where the table is saves a meeting every couple of years.

Reference material if you want to read primary sources: RFC 5280 for the IETF profile of X.509 v3, RFC 8446 for how X.509 fits into TLS 1.3, RFC 6960 for OCSP, and Wikipedia’s X.509 page for a serviceable overview if you only have ten minutes.