Public Key Infrastructure, explained.

Public Key Infrastructure (PKI) is the machinery that answers a deceptively hard question: how do two parties who have never met establish trust over a network where anyone can claim to be anyone? It's the system underneath the padlock in your browser, the checkmark that says a piece of software really came from its publisher, and the signature that proves an email wasn't tampered with in transit. Strip away the acronym and PKI is really three ideas working together — a mathematical relationship between two keys, a way to prove authorship without revealing a secret, and a network of trusted parties who vouch for who owns what key. This article builds that picture from the ground up, and pairs directly with our companion piece on TLS certificates and Certificate Transparency, which covers the web-specific chain of trust in more depth.

The key pair at the center of everything

PKI is built on asymmetric cryptography — a pair of mathematically related keys, one public and one private, where an operation done with one key can only be reversed or verified with the other. We cover the deeper mechanics of symmetric versus asymmetric cryptography in cryptography basics; the short version here is enough to build on: generate a key pair once, keep the private key secret and never let it leave your control, and hand the public key out freely to literally anyone.

The relationship between the two keys unlocks two distinct capabilities, and it's easy to get them backwards:

In practice, real-world algorithms are RSA or elliptic-curve schemes like ECDSA and Ed25519 — the math differs, but the roles of "public key encrypts or verifies" and "private key decrypts or signs" hold across all of them.

Digital signatures: proving authorship without a shared secret

A digital signature is what lets PKI prove authenticity and integrity at the same time, and it works in three steps. First, the signer runs the message through a cryptographic hash function, producing a short, fixed-length fingerprint of the content. Second, the signer encrypts that hash with their own private key — this encrypted hash is the signature. Third, anyone with the signer's public key can decrypt the signature back into the original hash, independently re-hash the message they received, and compare the two. If they match, two things are simultaneously true: the message came from someone holding that private key, and the message hasn't been altered by so much as a single byte since it was signed — changing anything in the content changes its hash completely, breaking the match.

This gives PKI three properties that plain passwords or shared secrets can't provide on their own:

• Authenticity — the signature could only have been produced by the private key's holder.
• Integrity — any tampering with the signed content, however small, invalidates the signature.
• Non-repudiation — assuming the private key wasn't compromised, the signer can't credibly deny having signed it, because no one else could have produced a valid signature.

Notice what a signature does not prove on its own: it says nothing about who the key's owner actually is in the real world. A key pair generated five minutes ago by anyone, anywhere, can produce perfectly valid signatures. Binding a public key to a verified real-world identity is exactly the job of the next piece: the certificate.

Certificates: binding a key to an identity

A digital certificate is a small, signed data structure that says, in effect, "this public key belongs to this identity, and I — a trusted party — vouch for that." The dominant format is X.509, and every certificate you'll encounter, whether for a website, a piece of signed software, or an email address, carries roughly the same core fields:

That last field is the whole trick: the certificate authority doesn't just assert the binding between key and identity, it cryptographically signs that assertion using its own private key — which means verifying a certificate is itself just another signature check, chained one level up.

Certificate authorities and the chain of trust

A certificate authority (CA) is an organization whose job is verifying that whoever requests a certificate actually controls the identity — a domain, an email address, an organization — they're claiming, and then issuing a signed certificate attesting to that. Your browser, operating system, and email client each ship with a curated list of root CAs they trust by default. Every certificate they'll accept has to trace back to one of those roots through an unbroken chain of signatures: a root CA signs an intermediate CA's certificate, and that intermediate signs the actual certificate you're presented with day to day. Root keys are kept offline and used as rarely as possible, precisely because a compromised root would be catastrophic — if an intermediate is ever compromised instead, it can be revoked and replaced without touching the root at all.

This chain-of-trust model, and the specific mechanics of how it plays out for web certificates — including Domain, Organization, and Extended Validation levels, and the Certificate Transparency logs that keep certificate authorities honest — is covered in full in TLS certificates and Certificate Transparency. What matters here is the general pattern: trust doesn't come from any single certificate being self-evidently correct, it comes from a verifiable chain of signatures rooted in a small set of parties that a huge number of independent systems have agreed, in advance, to trust.

Where PKI actually gets used

TLS is PKI's most visible application, but the same public-key-plus-certificate model quietly runs several other systems most people interact with daily:

Client certificates are worth calling out because they flip the usual direction: in ordinary TLS browsing, the server proves its identity to you. In mutual TLS (mTLS), both sides present certificates, so the server can also verify exactly which device or user is connecting — the model behind smart-card logins, many corporate VPNs, and service-to-service authentication inside a company's own infrastructure.

Generating and inspecting a certificate yourself

None of this requires special access to observe — the entire lifecycle of a key pair and a certificate is a few OpenSSL commands away, and walking through it once turns the abstract diagram above into something concrete. Generate a private key, request a certificate for it, and then look at exactly what fields end up inside:

# Generate an elliptic-curve private key (the public key is derivable from it)
$ openssl ecparam -name prime256v1 -genkey -noout -out private.key

# Create a Certificate Signing Request (CSR) — what you'd hand to a real CA
$ openssl req -new -key private.key -out request.csr -subj "/CN=example.com"

# For local testing, self-sign it instead of sending it to a CA
$ openssl x509 -req -in request.csr -signkey private.key \
    -out selfsigned.crt -days 365

# Inspect any certificate's actual fields
$ openssl x509 -in selfsigned.crt -noout -text | head -12
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4a:1f:...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=example.com
        Validity
            Not Before: Jul 22 00:00:00 2026 GMT
            Not After : Jul 22 00:00:00 2027 GMT
        Subject: CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey

A self-signed certificate like this one carries all the same fields as one issued by a real CA — subject, issuer, validity window, public key, signature — except its Issuer and Subject are identical, and no browser or operating system will trust it, because it wasn't signed by anything already in their trust store. That's the entire practical difference between "a certificate" and "a trusted certificate": the signature, and whether the party that produced it is one your software already agreed, in advance, to believe.

Revocation: what happens when a private key leaks

A certificate's validity period limits the blast radius of a compromise by design, but expiration dates alone are often too slow — a leaked private key needs to stop being trusted immediately, not whenever it happens to expire. Two mechanisms exist to make that possible:

• Certificate Revocation Lists (CRLs) — a signed, published list of certificate serial numbers a CA has revoked before their natural expiry. Clients can download and check against it, though CRLs can grow large and aren't always checked in real time.
• Online Certificate Status Protocol (OCSP) — a live, per-certificate query: a client asks "is this specific certificate still valid?" and gets a real-time signed answer back, avoiding the need to download an entire list.

Revocation only protects what happens next, though. It doesn't undo anything already signed with a compromised key before the compromise was discovered — which is exactly why key management (keeping private keys offline, hardware-protected, and access-controlled) matters as much as the cryptography itself. The strongest algorithm in the world doesn't help if the private key behind it sits in a world-readable file.

The takeaway

PKI is not one technology but a layered system: asymmetric key pairs make signing and encryption possible, digital signatures let anyone verify authorship and integrity without a shared secret, certificates bind a public key to a real identity, and certificate authorities extend that binding into a chain of trust that browsers, operating systems, and mail clients agree to honor in advance. The same pattern shows up whether you're loading a website, installing signed software, reading a verified email, or connecting to a corporate VPN with a smart card — different certificates, same underlying machinery. Understanding that machinery is what turns "the padlock means it's secure" into an actual, verifiable claim about who controls which key.

Frequently asked questions