A Public Key Infrastructure (PKI) is less about secure communication and more about verifiable identity in a world where you can’t physically meet everyone.
Imagine you’re trying to send a secret message to Alice. You could encrypt it with a key, but how does Alice know that the key you sent her is really yours, and not from Bob trying to impersonate you? PKI solves this by introducing trusted third parties called Certificate Authorities (CAs).
Here’s a simple scenario: Alice wants to send me a message. She needs to be sure it’s really me receiving it.
{
"sender": "Alice",
"recipient": "Me",
"message": "Let's meet at 3 PM.",
"signature": "signed_by_my_private_key"
}
But how does Alice get my public key to verify my signature? She can’t just ask me for it; I might be an imposter. This is where PKI shines.
A Certificate Authority (CA) is like a digital notary. When I want to prove my identity, I generate a public/private key pair. I then send my public key, along with proof of my identity (like a domain name registration or company details), to a CA. The CA verifies my identity and then issues a digital certificate. This certificate is essentially a signed statement from the CA saying, "This public key belongs to [My Identity]."
{
"identity": "my_domain.com",
"public_key": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----",
"issuer": "Let's Encrypt",
"validity_period": {
"not_before": "2023-10-27T00:00:00Z",
"not_after": "2024-01-25T23:59:59Z"
},
"signature": "signed_by_LetsEncrypt_private_key"
}
When Alice receives my certificate, she doesn’t trust me directly. Instead, she trusts the CA that issued my certificate. Most operating systems and browsers come pre-loaded with a list of trusted root CAs. Alice’s system checks if the CA that issued my certificate is in its trusted list. If it is, and the CA’s signature on my certificate is valid (meaning it hasn’t been tampered with), then Alice can trust that the public key in my certificate truly belongs to me. She can then use this public key to verify my signature on the message.
This forms a trust chain. My certificate is signed by an intermediate CA, which might be signed by another intermediate CA, all the way up to a root CA that is inherently trusted by Alice’s system. If any link in this chain is broken or untrusted, the entire chain of trust fails.
The most surprising thing about PKI is how much of its security relies on the revocation process, which is often its weakest point. A certificate is only valid until its expiration date, but it can also be invalidated before then if the associated private key is compromised. This is done through Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) checks. Systems are supposed to query these to ensure a certificate hasn’t been revoked. However, many clients, for performance or simplicity, skip these checks, especially for SSL/TLS certificates, effectively trusting expired or compromised certificates until their natural expiry.
The next concept you’ll run into is how this trust is applied in practice, particularly with TLS/SSL for secure web browsing.