The Problem PKI Exists to Solve
Asymmetric encryption gives everyone a public key they can share and a private key they keep secret. It is elegant, but it has a gap: encryption works only if you use the genuine public key of the party you mean to talk to. Over an untrusted network, anyone can intercept a connection and present their own public key while claiming to be your bank. The math would still work flawlessly — you would just be encrypting everything for the attacker.
So the hard problem is not secrecy; it is authenticity — binding a public key to a verified identity in a way strangers can check. PKI is the infrastructure built specifically to answer "does this key really belong to who it says?" Everything in it serves that one purpose.
The Pieces, and How They Fit
PKI is best understood as a set of cooperating parts, each of which the wider guides cover in depth. Seen together, they form a pipeline from raw keys to verifiable trust:
| Component | Its role in the system |
|---|---|
| Key pairs | The public/private keys at the foundation; the public one is what gets bound to an identity |
| Certificates | A signed document binding a public key to an identity (a domain, person, or device) |
| Certificate authorities | Trusted organizations that verify identities and sign certificates |
| Registration / validation | The process of proving identity before a certificate is issued — submitted via a CSR |
| Trust stores | The list of root certificates a device trusts by default |
| Revocation | Mechanisms to cancel a certificate that can no longer be trusted |
How Trust Actually Flows
The genius of PKI is that it lets you trust millions of certificates you have never seen, by trusting a tiny number of roots in advance. Trust flows downward through a chain:
- Your device ships with a trust store of root certificates from established certificate authorities. These you trust by default — the trust has to bottom out somewhere.
- A root authority signs intermediate certificates, delegating its authority while keeping the precious root key offline.
- Intermediates sign end-entity certificates — the certificate a website actually presents.
- When you connect, your device verifies each digital signature up the chain. If the path leads to a root in your trust store, the certificate is trusted.
This is why the system scales. No one has to pre-approve individual websites; they only have to trust the handful of authorities at the top, and the signatures do the rest. The trade-off is that those authorities carry enormous responsibility — a CA that issues a fraudulent certificate, or whose key is compromised, can undermine trust for everyone relying on it, which is why CAs operate under strict, audited rules.
What a Certificate Binds Together
A certificate is the linchpin object in all of this. Stripped down, it asserts three things in one signed package: this identity (a domain name, say), owns this public key, and a particular authority vouches for it until an expiry date. The authority's signature is what makes the binding believable — anyone can verify it using the authority's own public key, and any tampering would invalidate it. A certificate also has a defined lifetime; short lifetimes have become the norm precisely because they limit how long a mistakenly issued or quietly compromised certificate can do harm, reducing reliance on the imperfect revocation step.
PKI Is Bigger Than HTTPS
It is easy to equate PKI with HTTPS because the web is where most people meet it, but TLS is only one consumer of the infrastructure. The same machinery of keys, certificates, and signing authorities underpins a wide range of trust problems: email signing and encryption, code signing that proves software came from a genuine publisher and was not altered, signed documents, and the device identity that lets machines authenticate to each other — including mutual TLS, where the client holds a certificate too. PKI is the general-purpose answer to "prove this key belongs to who it claims," and TLS is simply its most famous application. Wherever two parties need to trust each other's keys at scale, some form of PKI is usually doing the work underneath.
Frequently Asked Questions
What is PKI?
Public key infrastructure — the combined system of technologies, roles, and policies that creates, distributes, and manages digital certificates and the public keys inside them. It lets parties who have never met trust each other by tying a public key to a verified identity through a signed certificate. HTTPS is its most visible product.
What are the main components of PKI?
Public/private key pairs, digital certificates that bind a key to an identity, certificate authorities that issue and sign them, registration processes that verify identity, trust stores holding the trusted roots, and revocation mechanisms to cancel certificates that can no longer be trusted.
What problem does PKI solve?
Trusting a public key received over an untrusted network. Asymmetric encryption needs each party to use the other's genuine key, but anyone can claim a key belongs to a given site. PKI proves authenticity — that a key really belongs to who it claims — by having a trusted authority vouch for the binding in a signed certificate.
Is PKI the same as TLS?
No. PKI is the broader system of keys, certificates, authorities, and trust. TLS is one protocol that uses PKI for the certificates that authenticate servers. PKI also underpins email signing, code signing, document signatures, and device identity, so TLS is just one application.
What is a chain of trust in PKI?
The path of signatures linking a certificate back to a trusted root. A root signs intermediates, intermediates sign end-entity certificates, and a device trusts the result because the root is in its trust store. Each link is verified by a digital signature, so trust flows down from the root.