What is X.509

X.509 is the standard that defines the format of public key certificates. Every TLS certificate, code signing certificate, S/MIME certificate, and CA certificate follows the X.509 structure. Originally defined by ITU-T in 1988 and profiled for internet use by RFC 5280 (PKIX), X.509 specifies exactly what fields a certificate contains, how they’re encoded (ASN.1/DER), and how certificate chains are validated. When you inspect a certificate in a browser or with OpenSSL, you’re reading X.509 fields.

Why it matters

• Universal format — every certificate in the TLS ecosystem is X.509v3. Browsers, servers, CAs, and PKI tools all speak this format. There’s no alternative for public PKI.
• Extensions define policy — X.509v3 extensions (Subject Alternative Names, Key Usage, Basic Constraints) control what a certificate is allowed to do. A certificate without the right extensions is useless or dangerous.
• Chain validation rules — RFC 5280 defines exactly how clients validate certificate chains: checking signatures, validity periods, name constraints, path length, key usage, and revocation status. Every TLS library implements these rules.
• Encoding matters — X.509 uses ASN.1 with DER encoding. Format conversion between PEM (base64-encoded DER), DER (binary), PKCS#12 (bundled with key), and PKCS#7 (chain without key) is a constant operational task.
• Interoperability — because X.509 is standardized, a certificate issued by any CA works with any compliant client. The standard is what makes the multi-vendor PKI ecosystem possible.

How it works

X.509v3 certificate structure:

1. Version — v3 (the only version used today; v1 and v2 lack extensions)
2. Serial Number — unique identifier assigned by the CA (used in CRLs and OCSP)
3. Signature Algorithm — algorithm the CA used to sign (e.g., sha256WithRSAEncryption, ecdsa-with-SHA256)
4. Issuer — Distinguished Name of the CA that signed this certificate
5. Validity — notBefore and notAfter timestamps
6. Subject — Distinguished Name of the certificate holder (CN, O, OU, C)
7. Subject Public Key Info — the public key and its algorithm (RSA 2048, ECDSA P-256, etc.)
8. Extensions (v3):
   • Subject Alternative Names (SAN) — the actual identities (DNS names, IPs, emails)
   • Key Usage — what the key can do (digitalSignature, keyEncipherment, keyCertSign)
   • Extended Key Usage — specific purposes (serverAuth, clientAuth, codeSigning)
   • Basic Constraints — is this a CA certificate? What’s the path length limit?
   • Authority Information Access — OCSP responder URL, CA issuer URL
   • CRL Distribution Points — where to find the CRL
   • Certificate Policies — OIDs indicating DV, OV, or EV validation level
9. Signature — the CA’s digital signature over all the above fields

In real systems

Inspecting a certificate with OpenSSL:

openssl x509 -in cert.pem -noout -text

# Key output:
# Version: 3 (0x2)
# Serial Number: 04:a1:b2:c3:...
# Signature Algorithm: sha256WithRSAEncryption
# Issuer: C=US, O=Let's Encrypt, CN=R3
# Validity:
#   Not Before: Mar 1 00:00:00 2026 GMT
#   Not After : May 30 23:59:59 2026 GMT
# Subject: CN=example.com
# Subject Public Key Info:
#   Public Key Algorithm: id-ecPublicKey (P-256)
# X509v3 Extensions:
#   X509v3 Subject Alternative Name:
#     DNS:example.com, DNS:www.example.com
#   X509v3 Key Usage: critical
#     Digital Signature
#   X509v3 Extended Key Usage:
#     TLS Web Server Authentication
#   X509v3 Basic Constraints: critical
#     CA:FALSE

Format conversions:

# PEM to DER
openssl x509 -in cert.pem -outform DER -out cert.der

# PEM to PKCS#12 (for IIS, Java)
openssl pkcs12 -export -in cert.pem -inkey key.pem -certfile chain.pem -out cert.pfx

# PKCS#12 to PEM
openssl pkcs12 -in cert.pfx -out cert.pem -nodes

Subject vs SAN (critical distinction):

# Old way (deprecated): identity in Subject CN
Subject: CN=www.example.com

# Modern way: identity in SAN extension (RFC 6125)
X509v3 Subject Alternative Name:
  DNS:example.com, DNS:www.example.com, DNS:api.example.com

# Browsers check SAN first. If SAN exists, CN is ignored.
# If SAN is missing, some clients fall back to CN (but this is deprecated).

Where it breaks

Missing SAN extension — a certificate has CN=api.example.com in the Subject but no SAN extension. Modern browsers and libraries (Go, Python requests, curl) require the SAN extension and ignore the CN. The certificate is rejected with “hostname mismatch” even though the CN matches. Always include SANs — the CN is effectively decorative in modern TLS.

Wrong Key Usage — a certificate has Key Usage: keyEncipherment but is used with ECDSA (which needs digitalSignature). Or a CA certificate lacks keyCertSign, so certificates it signs fail chain validation. Key Usage mismatches cause cryptic validation errors that are hard to diagnose without inspecting the certificate extensions directly.

Path length constraint violation — a Root CA signs an Intermediate with pathLenConstraint:0 (meaning the Intermediate can sign end-entity certs but NOT other Intermediates). Someone creates a sub-Intermediate under it. Certificates from the sub-Intermediate fail validation because the path length is exceeded. Clients that enforce path length (Java, Go) reject the chain; some others (older OpenSSL) may not check.

Operational insight

The most common X.509 operational pain is format conversion. You receive a certificate from a CA in PEM format, but IIS needs PFX, Java needs JKS, and the load balancer needs the chain in a specific order. Each conversion is a potential failure point: wrong chain order, missing intermediate, key not included, password encoding issues. Standardize on PEM internally (it’s human-readable and universally supported) and convert to target formats only at deployment time. Automate the conversion — manual format juggling is where certificates get corrupted or chains get assembled incorrectly.

Related topics

• What is a TLS Certificate
• What is a Certificate Authority
• What is PKCS
• Digital Signatures
• Certificate Lifecycle Stages