What Is PKI? Public Key Infrastructure Explained

Public key infrastructure (PKI) is the set of roles, policies, and systems that let two parties who have never met trust that a given public key really belongs to the entity it claims to represent. Every time a browser shows a padlock next to a URL, PKI is the machinery underneath it — a chain of digital signatures vouching for a public key, all the way back to a root that both sides already trust.

Public-key cryptography solves half the trust problem on its own: if you have someone’s public key, you can encrypt messages only they can read, or verify signatures only they could have produced. The half it doesn’t solve is how do you know that key actually belongs to them and not an attacker. PKI is the answer.

The core building blocks

• Key pairs. Each entity — a server, a person, a device — holds a private key it keeps secret and a public key it can hand out freely. See how digital signatures work for the math underneath.
• Certificates. A certificate binds a public key to an identity (a domain name, an organization, a person) and is itself digitally signed by someone else vouching for that binding. X.509 is the near-universal certificate format.
• Certificate authorities (CAs). Organizations trusted to verify identity and sign certificates. Operating systems and browsers ship with a curated list of root CA public keys they trust by default.
• Chains of trust. A root CA rarely signs end-entity certificates directly. Instead it signs intermediate CA certificates, and an intermediate signs the certificate your server actually presents. Verifying a certificate means walking this chain back to a trusted root.

How a TLS handshake uses it

When your browser connects to a site over HTTPS, the server presents its certificate. The browser checks three things: that the certificate’s signature chains up to a trusted root, that the domain name matches, and that the certificate hasn’t expired or been revoked. Only after that verification does the TLS handshake proceed to establish a shared session key. PKI is what makes the “is this really example.com?” question answerable before any encrypted data flows.

Revocation: the weak link

Certificates get compromised or issued in error, and PKI needs a way to invalidate them before their expiry date. Two mechanisms handle this, each with tradeoffs — see OCSP vs CRL for the details. Revocation checking is also where certificate pinning and certificate transparency logs come in, as additional layers that make it harder for a fraudulently issued certificate to go unnoticed.

Where PKI shows up beyond the browser padlock

• Code signing. Software publishers sign binaries and updates so operating systems can verify a package hasn’t been tampered with before installing it.
• Client authentication and mTLS. In mutual TLS, both sides present certificates — not just the server. This is common between internal services that need strong identity guarantees without passwords.
• Email (S/MIME) and VPNs. Both rely on the same certificate-and-CA model to establish who’s who before exchanging anything sensitive.
• JWTs signed with RS256/ES256. The issuer’s public key, distributed as part of a certificate or a JWKS endpoint, lets any relying party verify a token without contacting the issuer.
• Hardware and device identity. Manufacturers embed certificates into devices during production so a device can prove its identity to a backend without ever transmitting a shared secret.

Public vs private PKI

Public CAs, trusted by every major browser and OS out of the box, are for anything a stranger on the internet needs to trust — public websites, public APIs. Organizations also commonly run a private CA for internal use: certificates for internal services, employee devices, or machine-to-machine authentication inside a VPC, where you control every relying party and don’t need public trust. Kubernetes clusters, for instance, typically run their own internal CA to issue certificates between control-plane components.

Why the trust model still holds

The entire system rests on a small number of root keys being kept extremely secure and on CAs actually verifying identity before they sign. A compromised root CA, or a CA that signs certificates without proper verification, breaks the guarantee for everyone who trusts it — which is why root key ceremonies are heavily audited and why misbehaving CAs have historically been removed from browser trust stores entirely. PKI doesn’t eliminate the need for trust; it concentrates it into a small, auditable set of anchors instead of forcing every pair of strangers to establish trust from scratch.

The takeaway

PKI is the infrastructure that turns “here’s a public key” into “here’s a public key that’s provably owned by the entity it claims to represent.” Certificates bind identity to keys, CAs sign those bindings, and chains of trust let a browser or client verify the binding without ever talking to the CA directly. It’s invisible when it works — which is most of the time — and it’s the reason encrypted connections to strangers on the internet are something you can actually rely on.