Public Key Infrastructure: The Trust System Behind Every Padlock

Public key infrastructure, usually shortened to PKI, is the system that lets strangers trust each other’s keys on the internet. It is the people, the policies, the software and the checking routines that create, issue, manage and cancel digital certificates. A digital certificate is a small signed document that ties a public key to a name, such as a website address. When your browser shows a padlock beside that address, public key infrastructure is what gives it the confidence to do so.

Think of it as the passport system for computers. A passport works because a government office checked who you are, printed the result in a document that is hard to fake, and gave border officers a way to verify it and a way to cancel it. A public key infrastructure does the same job for websites, servers and software. This guide introduces the cast, follows the chain of trust link by link, compares the three levels of checking, and ends with the honest limits of what a certificate can prove.

Start with the key pair

Public key infrastructure builds on public key cryptography, a method where every participant holds a matched pair of keys. The public key is shared openly with anyone who wants it. The private key stays secret and never leaves its owner. The two keys work as opposites: anything the public key locks, only the private key can unlock, and a signature made with the private key can be checked by anyone holding the public key.

That trick solves half the problem of talking safely to strangers. It does not solve the other half. Anyone can generate a key pair in seconds and publish the public half while claiming to be your bank, your employer or your email provider. The key itself carries no name and no proof. A public key infrastructure exists to supply the missing proof: a checked, signed statement about whose key this really is.

Some systems skip the referee and rely on your own memory instead. An SSH key works exactly that way: your computer remembers a server’s key from the first visit and warns you loudly if the key ever changes. That approach works when you manage a handful of servers. The open web holds billions of sites, most of which you will visit once, and it needs a referee model instead.

Meet the cast

A public key infrastructure has more moving parts than the padlock suggests. Each part has one clear job, and the system works because no single part does two jobs that should stay separate. The certificate authority signs, the registration authority checks, and your own software decides whether the result deserves trust.

The exact shape of the certificate and the rules for checking it live in RFC 5280, the internet standard that profiles the X.509 format. It defines the fields inside a certificate, the structure of revocation lists, and the step-by-step algorithm software uses to validate a chain. Engineers who run one for a living treat that document as the rulebook.

How the chain of trust works

Certificates rarely stand alone. They form a chain, and the chain is how trust travels from a name you have never heard of to a root your device already trusts. A typical chain has three links. At the top sits a root certificate authority, which signs its own certificate and guards its private key with extreme care. Public roots keep that key offline, in hardened facilities, and bring it out only on rare, scripted occasions.

The root uses that guarded key to sign certificates for intermediate authorities, and the intermediates do the daily work of issuing certificates to websites and services. This layering limits the damage from any single failure. If an intermediate key is ever stolen or misused, the root can cancel that one intermediate, and the rest of the system carries on. Root keys almost never sign website certificates directly, precisely so they can stay offline.

Your side of the chain starts before you visit anything. Browsers and operating systems ship with a trust store, a built-in set of root certificates from authorities that passed public audits and strict admission programs. When you open an HTTPS site, the server presents its certificate plus the intermediate certificates above it. Your browser then follows the signatures upward, exactly as the path validation algorithm in RFC 5280 describes, until it reaches a root already in the trust store. It also checks that the name on the certificate matches the address you typed, that the dates are current, and that the certificate has not been revoked. Only then does the encrypted session begin, and the padlock appears.

That ceremony happens in a fraction of a second, on nearly every connection you make. Guidance from the US National Institute of Standards and Technology, in its practice guide SP 1800-16 on TLS server certificate management, shows how much quiet work sits behind it inside companies: tracking every certificate, renewing before expiry, and replacing keys without breaking services. Most outages caused by certificates are boring failures of that bookkeeping, not attacks.

Revocation: taking a certificate back

Every certificate carries an expiry date, but life does not always wait for it. A private key gets stolen, a company closes, an employee leaves, or a CA discovers it issued a certificate by mistake. Revocation is how a CA cancels a certificate early and tells the world to stop trusting it.

The older channel is the certificate revocation list, or CRL: a signed list of cancelled certificate serial numbers that the issuing CA publishes and updates on a schedule. Software downloads the list and checks against it. The newer channel is OCSP, the Online Certificate Status Protocol, where software asks the CA’s responder about one specific certificate and receives a signed answer: good, revoked or unknown. CRLs are simple and private but can grow large and lag behind events. OCSP answers are fresh and light, but the question itself can reveal which site you are visiting, so many browsers now lean on lists the browser maker itself ships and refreshes. Either way, the answer carries the CA’s signature, so an attacker cannot forge a clean bill of health for a cancelled certificate.

What a certificate proves, and what it does not

This is the section most explainers skip, and it matters more than any other. A valid certificate proves three things. A certificate authority ran its checks and found that the applicant controlled the domain, or, at higher levels, matched a real legal identity. The public key in the certificate belongs to that subject. And your traffic to the site travels encrypted to whoever holds the matching private key.

A certificate proves nothing about honesty. It does not say the business is competent, solvent or kind, and it does not say the page in front of you is safe. A phishing site can hold a perfectly valid certificate for its own lookalike domain, because the check it passed proves control of that domain, not good character. Read the padlock correctly: it means you are really talking to the owner of this address, over a private line. It does not mean the owner deserves your card number. That is why the padlock never replaces the habits in our computer virus prevention guide, such as checking addresses character by character and treating surprise download prompts as hostile.

Three levels of checking: DV, OV and EV

Not every certificate gets the same scrutiny before signing. Public CAs sell, and in the first case often give away, three levels of validation. The encryption that results is identical in all three. Only the identity checking behind the signature changes, under the shared rules that all public CAs follow, the CA/Browser Forum Baseline Requirements.

Here is the honest footnote the sales pages rarely print. Browsers once rewarded EV certificates with a company name in green inside the address bar. Google removed that display with Chrome 77 in 2019, after its own research found that visitors did not make safer choices because of it, and Firefox 70 removed its EV indicator the same year. Today a DV, OV and EV site all show the same plain padlock, and the extra identity detail hides behind a click on the connection panel. EV still records the deepest checks, but it no longer buys a more impressive badge.

Where public key infrastructure quietly runs the world

HTTPS is the sighting everyone knows, but PKI turns up anywhere a machine must prove its name before it is trusted. Software downloads are one example. When Windows or macOS runs an installer, it checks the publisher’s code signing certificate, which proves the file came from the named developer and has not been altered since signing. Security teams lean on the same signatures at scale, and a corporate software inspector builds on them to flag tampered or unknown programs across a whole fleet.

Email uses it too. S/MIME, the signing standard built into Outlook and other mail clients, attaches a certificate to your mail so receivers can verify the message came from you, and can encrypt replies so only you can read them. Legal and finance teams sign documents the same way: a signature certificate lets a reader verify a contract years later and prove the file has not changed since the day it was signed. And when you connect to the office network, the gateway often presents a certificate before it lets you in, which is one of the quiet ways a virtual private network confirms you reached the real company front door and not an impostor. Add the certificates inside phones, laptops, bank cards and a growing crowd of connected devices, and the pattern is clear: modern computing runs on checked names, and PKI is the checking.

Conclusion

Public key infrastructure is the trust system that turns raw key pairs into names the whole internet can rely on. Registration authorities check who is asking, certificate authorities sign the result into X.509 certificates, intermediates and offline roots form a chain your device can verify, and revocation lists and status services handle the cancellations. A certificate proves control of a name, never good character, and knowing that one limit makes you harder to fool than any padlock can.