X.509 is the standard that defines the format of public key certificates and certificate revocation lists, binding a public key to an identity such as a domain name, an organization or a person. In Internet trust it is the data structure behind HTTPS, signed email, code signing and VPN authentication: a certificate authority signs the binding, and anyone who trusts that authority can verify it.
The name comes from the ITU-T X.500 directory series, but the Internet uses the profile in RFC 5280, commonly called PKIX. Current certificates are version 3, whose extensions make the format flexible enough to describe what a key may be used for and under which policy it was issued.
What an X.509 certificate contains
An X.509 certificate has three parts: the to-be-signed data, the identifier of the signature algorithm, and the issuer’s digital signature over that data. The structure is encoded in ASN.1 with the Distinguished Encoding Rules (DER), and it is often exchanged as Base64 text in PEM format.
| Field | Content | Why it matters |
|---|---|---|
| Version | Usually v3 | Enables extensions |
| Serial number | Unique per issuer, up to 20 bytes | Identifies the certificate for revocation |
| Issuer | Distinguished name of the signing CA | Links the certificate to its chain |
| Validity | notBefore and notAfter timestamps | Defines the usable lifetime |
| Subject | Distinguished name of the holder | Identity, though browsers use SAN for names |
| Subject public key info | Algorithm and public key | The key being certified |
| Extensions | Typed, optionally critical attributes | Constrain how the key may be used |
A verifier checks the signature with the issuer’s public key, which it takes from the next certificate up the chain. The process repeats until it reaches a trust anchor, a root certificate already present in the operating system or browser trust store.
Extensions that control certificate use
Version 3 extensions turn a simple name-to-key binding into a policy-carrying credential. Each extension can be marked critical, which means a verifier that does not understand it must reject the certificate.
| Extension | Purpose | Typical value |
|---|---|---|
| Subject Alternative Name | Lists the names the certificate is valid for | DNS names, IP addresses, email addresses |
| Basic Constraints | States whether the holder is a CA | CA:TRUE with path length on intermediates |
| Key Usage | Allowed cryptographic operations | digitalSignature, keyCertSign |
| Extended Key Usage | Allowed applications | serverAuth, clientAuth, codeSigning |
| Name Constraints | Limits names a CA may certify | Permitted domain subtrees |
| Authority Information Access | Where to find the issuer and OCSP responder | OCSP and CA Issuers locations |
| CRL Distribution Points | Where revocation lists are published | One or more CRL locations |
For TLS server certificates, browsers ignore the subject common name and match the hostname only against the Subject Alternative Name. A certificate without a matching SAN entry fails validation even if the common name looks correct.
Path validation and revocation
Certification path validation is the algorithm that decides whether a certificate is trustworthy. It checks every signature, validity period, Basic Constraints, name constraints, key usage and policy along the certificate chain, and it stops at the first failure.
Revocation lets a CA withdraw a certificate before it expires, for example after key compromise. Certificate revocation lists (CRLs) are signed lists of revoked serial numbers, while OCSP answers a query about one certificate; both mechanisms have well-known limits in latency, privacy and soft-fail behavior.
| Approach | How it works | Main weakness |
|---|---|---|
| CRL | Client downloads a signed list of revoked serials | Large files, infrequent updates |
| OCSP | Client asks a responder about one certificate | Privacy leak and extra round trip |
| OCSP stapling | Server attaches a fresh signed OCSP response | Depends on server configuration |
| Browser-pushed lists | Vendor distributes compact revocation sets | Coverage decided by the vendor |
| Short-lived certificates | Lifetimes of days instead of a year | Requires reliable automation |
The industry has steadily shortened maximum TLS certificate lifetimes, from several years to 398 days, with further reductions agreed by browser vendors and CAs. Shorter lifetimes reduce reliance on revocation but make automated renewal, typically through the ACME protocol, effectively mandatory.
Certificate types and encodings in practice
The same X.509 format serves very different roles, distinguished by extensions and by the validation level the CA performed. Domain validation proves control of a name, while organization and extended validation add checks of the legal entity.
| Format | Encoding | Typical content |
|---|---|---|
| PEM | Base64 text with header lines | Certificates, chains, keys |
| DER | Binary ASN.1 | Single certificate |
| PKCS#7 | Binary or Base64 | Certificate chain without private key |
| PKCS#12 | Binary, password-protected | Certificate chain plus private key |
- Serving an incomplete chain is the most common deployment error; clients that do not fetch missing intermediates then fail.
- Wildcard certificates cover one label only, so
*.example.comdoes not matcha.b.example.com. - Self-signed certificates provide encryption but no third-party identity assurance unless the root is distributed deliberately.
- Clock errors on devices cause valid certificates to appear expired or not yet valid.
A non-technical view
An X.509 certificate works like a digital passport for a website or a person. It states who the holder is, includes a key that only that holder can use, and carries the stamp of an issuing authority that others already trust.
When your browser connects to a bank, it checks this passport, confirms the stamp and verifies that the name matches the address you typed. If anything does not match, the browser warns you, because the identity cannot be confirmed.
A concrete example
An online retailer runs its shop on a cluster of web servers behind a load balancer. The operations team requests a TLS certificate whose Subject Alternative Name lists both the main domain and the www host, issued by a public CA through the ACME protocol with a 90-day lifetime.
The load balancer serves the leaf certificate together with the intermediate certificate and staples OCSP responses. When a monitoring check later reports that an old server still presents an incomplete chain, the team fixes the bundle before customers notice. Renewal runs automatically every 60 days, so no certificate expires unnoticed, and checkout pages keep working without browser warnings.