On this page
PKI and certificate authority fundamentals
The cryptographic trust framework that enables secure communication over untrusted networks via digital certificates and mathematical proof of identity.
Reference Card
- Origin/Prior Art: Diffie-Hellman Key Exchange, RSA algorithms.
- Related Practices: mTLS, Let’s Encrypt / ACME protocol, Zero-Trust networks.
- Key Concepts: Asymmetric encryption, Private/Public key pairs, Chain of Trust.
- Primary Failure Modes: Leaking the root private key, Trusting self-signed certificates in production without distributing the root CA.
Introduction
TLS encryption (HTTPS) guarantees that no one can read the data flowing between a client and a server. But encryption alone is useless if you are communicating with an impostor. If an attacker intercepts your traffic and sets up an encrypted connection with you, the math works perfectly, but you are securely handing your password to a hacker.
Public Key Infrastructure (PKI) is the mathematical and operational framework that solves the identity problem. It ensures that when your browser connects to bank.com, the server on the other end is cryptographically proven to be owned by the actual bank.
Mental Model
Think of a physical passport. You (the client) want to verify that the person in front of you is John Doe. John hands you a passport (a Digital Certificate). You don’t trust John inherently, but you look at the passport and see the physical stamp and watermark of the United States Government (the Certificate Authority, or CA). Because you trust the US Government to verify identities before issuing passports, and because you recognize their unforgeable stamp (the Cryptographic Signature), you mathematically transfer your trust to John.
Operational Pattern
PKI relies on Asymmetric Encryption, where a server generates two mathematically linked keys: a Public Key (which it shares with the world) and a Private Key (which it guards with its life).
- The CSR (Certificate Signing Request): A server generates a key pair. It packages its Public Key and its domain name (
api.company.com) into a CSR and sends it to a Certificate Authority (CA) like Let’s Encrypt. - Verification: The CA challenges the server to prove it actually owns
company.com(usually by placing a specific file on the web server or adding a DNS record). - The Issuance: Once verified, the CA takes the server’s Public Key, bundles it into a Certificate, and signs it using the CA’s own Private Key.
- The Handshake: When a client connects to the server, the server presents this Certificate. The client checks its internal list of trusted CAs (which comes pre-installed in the operating system or browser). If it finds the matching CA’s Public Key, it mathematically verifies the signature on the server’s certificate.
Failure Modes
Leaking the Private Key
The entire security of a server relies on the absolute secrecy of its Private Key. If a developer accidentally commits a server’s .key file to a public GitHub repository, an attacker can spin up a rogue server, attach the leaked key and the matching public certificate, and perfectly impersonate the legitimate server. When a key is leaked, the certificate must be immediately mathematically revoked via CRL (Certificate Revocation List) or OCSP.
Internal Self-Signed Certificates
When building internal microservices, developers often generate “self-signed” certificates to enable HTTPS. Because no recognized CA signed these certificates, other microservices will throw SSL validation errors and refuse to connect. Developers “solve” this by configuring the application code to blindly ignore SSL errors (e.g., rejectUnauthorized: false in Node.js). This completely destroys the security of the connection, rendering the encryption vulnerable to trivial Man-in-the-Middle attacks.
Security
In modern cloud infrastructure, external PKI (Let’s Encrypt) secures the public edge, but Internal PKI secures the microservices. A service mesh (like Istio or Linkerd) acts as an automated internal Certificate Authority. It generates a unique certificate for every single Pod in the cluster, automatically rotates them every few hours, and enforces mutual TLS (mTLS). In mTLS, the server verifies the client’s certificate, and the client verifies the server’s certificate, ensuring cryptographic identity verification in both directions before a single byte of data is exchanged.
Operational Guidance
Never disable SSL verification in application code, even in staging environments. If you need internal TLS, stand up an internal Certificate Authority (using HashiCorp Vault, AWS ACM Private CA, or cert-manager in Kubernetes). Distribute the internal CA’s root certificate to your internal servers so they trust each other cryptographically, mimicking the exact behavior of public PKI.