Public Key Infrastructure (PKI) and X.509 Certificates Explained

Public Key Infrastructure (PKI) is the system of policies, roles, and technologies that binds public keys to real-world identities so that strangers on a network can trust one another. At its heart are X.509 certificates, the standardized digital documents that assert "this public key belongs to this entity," signed by a trusted authority. PKI is what makes TLS, secure email, code signing, and much of internet trust possible. Understanding how PKI and X.509 certificates work is essential for anyone securing networked systems.

The Problem PKI Solves

Public-key cryptography lets anyone encrypt to, or verify signatures from, a party using that party's public key. But there is a gap: how do you know a public key really belongs to the server or person you think it does? An attacker could substitute their own key in a man-in-the-middle position. Diffie-Hellman and digital signatures protect the channel only once you trust the keys involved.

PKI solves this binding problem by having a trusted third party, a Certificate Authority (CA), vouch for the association between an identity and a public key. The CA's endorsement takes the form of a signed certificate.

Anatomy of an X.509 Certificate

An X.509 certificate is a structured document (encoded in ASN.1 DER, often stored in PEM text form) containing standardized fields. Key elements include:

• Subject: the identity the certificate is issued to, such as a domain name or organization.
• Subject Public Key: the public key being bound to that identity, along with its algorithm (for example RSA or an elliptic curve).
• Issuer: the CA that signed and issued the certificate.
• Validity period: the not-before and not-after dates bounding when the certificate is usable.
• Serial number: a unique identifier assigned by the issuer.
• Extensions: additional constraints and metadata, such as Subject Alternative Names (SAN) listing valid domains, key usage restrictions, and basic constraints indicating whether the certificate may act as a CA.
• Signature: the issuer's digital signature over all of the above, which is what makes the certificate tamper-evident.

The signature is computed over a hash of the certificate contents, so any modification invalidates it. Verifying that signature with the issuer's public key is the core trust operation.

The Chain of Trust

Certificates form a hierarchy called the chain of trust, which typically has three tiers:

1. Root CA: a self-signed certificate at the top. Root CAs are distributed in operating systems and browsers as pre-trusted trust anchors and are guarded extremely carefully, often kept offline.
2. Intermediate CA: signed by the root (or another intermediate), an intermediate certificate does the day-to-day issuing. Using intermediates keeps the root key offline and limits damage if an intermediate is compromised.
3. Leaf (end-entity) certificate: issued to the actual server, user, or device.

When a client validates a certificate, it builds a path from the leaf up to a trusted root, checking at each step that:

• Each certificate's signature verifies against the next certificate up the chain.
• Each certificate is within its validity period and not revoked.
• Constraints such as basic constraints, name constraints, and key usage are satisfied.
• The leaf's Subject Alternative Name matches the expected identity (for example the hostname being visited).

If a complete, valid path reaches a trusted root, the certificate is accepted.

# Inspecting a certificate chain with OpenSSL
$ openssl s_client -connect example.com:443 -showcerts
$ openssl x509 -in cert.pem -noout -text   # human-readable fields

How Certificates Are Issued

A subject obtains a certificate by generating a key pair and submitting a Certificate Signing Request (CSR), which contains the public key and identity information and is signed with the corresponding private key to prove possession. The CA then performs validation before issuing:

• Domain Validation (DV): proves control of a domain, often via an automated challenge. This is what protocols like ACME automate.
• Organization Validation (OV) and Extended Validation (EV): additionally verify the requesting organization's legal identity, with more rigorous checks.

Crucially, the subject's private key never leaves their control; the CA only ever sees and signs the public key.

Revocation: Handling Compromised Certificates

Sometimes a certificate must be invalidated before it expires, for example if the private key is stolen. PKI provides revocation mechanisms:

• Certificate Revocation Lists (CRLs): signed lists of revoked certificate serial numbers published by the CA. They can grow large and are fetched periodically.
• Online Certificate Status Protocol (OCSP): a client queries the CA for the real-time status of a specific certificate. OCSP stapling improves privacy and performance by having the server obtain a signed status response from the CA and attach it during the handshake.
• Short-lived certificates: issuing certificates with brief validity reduces reliance on revocation altogether, since a compromised certificate expires quickly.

Revocation checking has historically been imperfect, which is one reason short validity periods and automated renewal have become preferred.

Trust, Weaknesses, and Good Practice

PKI's trust model has real limitations worth understanding:

• CA compromise is systemic. Because clients trust many CAs, a single misbehaving or breached CA can issue fraudulent certificates for any domain. Mitigations include Certificate Transparency, public append-only logs that make misissuance detectable.
• Trust store management matters. The set of trusted roots on a device defines its entire trust base; adding a rogue root undermines everything.
• Key protection is paramount. A leaked CA or leaf private key breaks the guarantees, so hardware security modules and strict access controls are standard.
• Name and constraint checking must be strict. Many historical attacks exploited lax hostname or constraint validation.

For defenders, sound PKI practice means automating issuance and renewal, monitoring Certificate Transparency logs, protecting private keys, and keeping trust stores up to date.

Key Takeaways

• PKI binds public keys to identities so parties can trust keys they have never seen before, solving public-key cryptography's identity-binding problem.
• An X.509 certificate contains a subject, public key, issuer, validity dates, extensions, and the issuer's signature that makes it tamper-evident.
• Trust flows through a chain from a leaf certificate up through intermediate CAs to a pre-trusted root CA acting as a trust anchor.
• Certificates are issued after validation of a CSR, and compromised certificates are handled through CRLs, OCSP, or short lifetimes.
• PKI's weakest points are CA compromise and trust-store integrity, mitigated by Certificate Transparency, strict validation, and strong key protection.