Concept Focus
Public Key Infrastructure (PKI) is the scaffolding that lets strangers trust each other on hostile networks. It is not a single product; it is the people, policies, software, keys, and protocols that make asymmetric cryptography usable at scale. At its core, PKI reliably answers three questions.
- Publish: how do we publish a public key so others can find and verify it?
- Bind: how do we prove this key belongs to that entity (a person, device, or service)?
- Validate: how do we check, right now, that the binding is still good?
Why PKI exists, the MITM problem
Without PKI, anyone in the middle can swap your peer's public key for their own, decrypt your traffic, then re-encrypt and forward it. PKI defeats this using digitally signed certificates issued by a Certificate Authority (CA) that everyone already trusts.
Core actors and artifacts
- Certificate Authority (CA): issues, signs, and anchors trust. Usually a Root CA (offline) and one or more Intermediate CAs (online).
- Registration Authority (RA): verifies identities on the CA's behalf (documents, in-person proofing, automated challenges).
- X.509 certificates: standardized containers for identity + public key + validity + CA signature.
- Keys: the public key (share broadly) and the private key (guard relentlessly).
- Status services: CRL (periodic lists of revoked certs) and OCSP (real-time certificate status).
Security services PKI enables
- Confidentiality (encrypt with the recipient's public key).
- Integrity (detect tampering).
- Authentication (prove identity).
- Non-repudiation (tie actions to identities with signatures).
- Access control enablement (cert-based auth, mutual TLS, VPN, device identity).
Trust chain
Certificate lifecycle (X.509)
CRL vs OCSP
A framework to publish, bind, and validate public keys via X.509 certificates signed by trusted CAs after RA identity proofing. It provides confidentiality, integrity, authentication, and non-repudiation, and enables access control. Status is checked via CRL (periodic) or OCSP (real-time, prefer stapling). Lifecycle discipline, enrollment to destruction, is where real-world PKI succeeds or fails.
Brain Ticklers
Q1. Neuromesh wants real-time revocation checks without leaking which sites users visit to an external responder. What is the best approach?
- Plain OCSP from clients to the CA
- OCSP stapling from the Neuromesh servers
- CRL checks every minute from clients
- Certificate pinning on all endpoints
Q2. Anya discovers a dev team exporting private keys to copy between containers. What is the primary control to stop this?
- Increase certificate validity to reduce renewals
- Use wildcards to simplify deployments
- Generate and store keys in an HSM, disable key export
- Switch to RSA-4096 from ECDSA
Q3. Which statement about RAs is most accurate in a high-assurance PKI?
- RAs issue certificates but cannot revoke them
- RAs neither issue nor sign; they vet identities and forward CSRs to the CA
- RAs sign OCSP responses for the CA
- RAs are optional when using a public CA
Q4. A customer portal cert chains to a trusted root, but browsers still warn. Which misconfiguration is the most likely culprit?
- Missing intermediate certificate in the server chain
- Using ECDSA instead of RSA
- OCSP stapling disabled
- CRL nextUpdate too far in the future
Q5. After an API gateway private key compromise, which sequence is most appropriate?
- Rotate DNS; renew cert later; investigate quietly
- Reissue cert with the same key; add pinning; publish a blog post
- Revoke affected certs immediately, generate new keypairs, reissue, redeploy, force OCSP stapling, update inventories, and record the incident internally
- Wait for regular renewal, then rotate
Short-lived certs beat revocation: a 90-day cert shrinks the risk window dramatically. Don't pin casually; pinning can brick recoveries if the CA path changes. mTLS is not magic; it only works if enrollment, key storage, and revocation are disciplined. Time matters; accurate NTP underpins validity windows, OCSP responses, and non-repudiation.
- PKI is governance + process + tooling, not just certificates.
- Put the root CA offline, intermediates controlled, keys in HSMs.
- Prefer automated enrollment (ACME), short-lived certs, and OCSP stapling.
- Treat the certificate lifecycle like code: inventory, alerts, renewals, rollbacks.
- Design for revocation at 3 a.m., not as an afterthought.