PKI Explained: A Complete Guide to Public Key Infrastructure

Imagine you want to send an encrypted message to someone you've never met. Asymmetric encryption requires their public key, but how do you know the public key actually belongs to them? Without PKI, an attacker could intercept your request and give you THEIR public key instead — a man-in-the-middle attack.

PKI solves this by using trusted third parties (Certificate Authorities) to verify identities and bind them to public keys through digital certificates. When you visit an HTTPS website, the server presents a certificate signed by a trusted CA. Your browser checks the signature, and if valid, you know you're talking to the real website. PKI is the reason you can securely buy things on Amazon without ever meeting them.

Certificate Authorities (CAs) are trusted entities that issue digital certificates. The CA verifies the certificate requester's identity (how thoroughly depends on the certificate type), then signs the certificate with the CA's private key.

Validation levels: Domain Validation (DV) — verifies domain ownership only (basic HTTPS). Organization Validation (OV) — verifies organization identity (business websites). Extended Validation (EV) — rigorous verification, green bar in browser (banks, financial sites).

CA hierarchy: Root CA (offline, self-signed, ultimate trust anchor) → Intermediate CA (online, issues certificates) → End-entity certificates (issued to websites, users, devices). Trust is maintained through certificate chaining — each certificate is signed by the one above it in the chain.

A digital certificate goes through several stages: Certificate Signing Request (CSR) — applicant generates a CSR containing their public key and identity information. Validation — CA verifies the applicant's identity. Issuance — CA signs and issues the certificate. Deployment — certificate is installed on the server. Revocation — if the private key is compromised or the certificate was issued in error, it's revoked via CRL or OCSP. Expiration — certificates have a validity period (typically 1-2 years) and must be renewed.

CRL (Certificate Revocation List) — a periodic list of revoked certificate serial numbers published by the CA. Clients download and check the CRL. Limitations: CRLs can be large, and there's a delay between revocation and publication.

OCSP (Online Certificate Status Protocol) — provides real-time status checking. The client sends the certificate serial to the OCSP responder and gets back: good, revoked, or unknown. Faster and more efficient than CRL.

OCSP Stapling — the web server periodically fetches the OCSP response and 'staples' it to the TLS handshake. Clients don't need to contact the OCSP responder themselves, improving performance and privacy.