Key exchange gets you a shared secret. Digital signatures prove authorship. But neither tells you who you are actually talking to. Certificates, certificate authorities, and TLS are the systems that bind identity to cryptography, turning raw primitives into the secure connections you use every day.
You performed a key exchange and derived a shared secret. But what if the other party is not who you think? An attacker who intercepts the key exchange and substitutes their own keys gets a perfectly valid shared secret with each side. The math works. The identity is wrong.
Digital signatures were supposed to fix this. Alice signs her key exchange message, and Bob verifies it with her public key. But where did Bob get Alice's public key? If an attacker substitutes their own public key, every signature they produce will verify perfectly.
You need a trusted public key to verify a signature. You need a signature to verify a public key. Something external has to break the circle. That something is a trusted third party who vouches for the binding between an identity and a public key.
The key distribution problem has been the central challenge of public-key cryptography since Diffie and Hellman proposed it in 1976. Every solution comes down to one question: who vouches for this public key?
Without certificates, an attacker can substitute their own public key and impersonate anyone.
Alice wants to send Bob a secure message. She needs his public key.
A certificate binds an identity to a public key, and a trusted third party signs the binding. If you trust the signer, you can trust the binding. The most widely used certificate format is X.509.
Think of a certificate as a cryptographic ID card. The photo (public key) is bound to the name (subject) by the stamp of the issuing authority (CA signature). You trust the ID card because you trust the authority that issued it.
The X.509 standard defines the format. A certificate contains the subject, the issuer, the public key, a validity period, a serial number, and a set of extensions that constrain how the key can be used. The issuer signs the entire structure with their private key.
The core binding. “This public key belongs to example.com.” The entire purpose of the certificate is this single claim.
The vouch. A CA signs the certificate with its own private key. Anyone who trusts the CA can verify this signature and trust the binding.
The constraints. When the certificate expires, what the key can be used for, which domain names it covers. Extensions make certificates flexible without changing the core format.
Click on any field of this X.509 certificate to learn what it does and why it matters.
A single certificate is not enough. The server's certificate is signed by an intermediate CA, which is signed by a root CA. Your browser validates the entire chain, verifying each signature up to a root it already trusts.
Root CA private keys are too valuable to use directly. If the root key were used for every certificate and then compromised, every certificate it ever signed becomes untrusted. Instead, the root signs a small number of intermediate CA certificates. The intermediates handle day-to-day issuance.
If an intermediate is compromised, only that intermediate is revoked. The root and other intermediates remain trusted. When you visit a site secured by Let's Encrypt, your browser validates exactly this structure: the leaf certificate for the domain, signed by the intermediate “R11”, signed by the root “ISRG Root X1” that ships preinstalled in your OS.
Everything depends on a small set of root certificates preinstalled in your operating system and browser. Apple maintains a trust store for macOS and iOS. Microsoft maintains one for Windows. Mozilla maintains one for Firefox. Roughly 150 root CAs secure the entire web, including ISRG Root X1 (Let's Encrypt), DigiCert Global Root G2, GlobalSign, and Google GTS Root R1.
Adding a new root CA requires passing rigorous audits (WebTrust, ETSI). Removing one happens when a CA violates its obligations or is compromised. The bar is high because the consequences are severe: every certificate issued under a removed root becomes untrusted overnight.
Step through what happens when an attacker obtains a root CA's private key.
A certificate chain connects a website's certificate to a root CA you trust. Click any certificate to inspect it. Break a link to see what happens.
The server must send the intermediate certificates along with its own certificate. The browser has the root certificates preinstalled, but it does not have intermediates. If the server forgets to send them, the chain is incomplete and validation fails. This is one of the most common TLS configuration errors.
Before any application data flows, client and server must agree on algorithms, exchange keys, and authenticate. TLS 1.3 does all of this in a single round trip. Key exchange, certificate verification, and symmetric encryption setup, combined into one protocol.
The client sends ephemeral ECDH key shares speculatively in the first message. The server picks one and responds. Both sides derive a shared secret without ever sending it over the wire.
The server sends its certificate chain. The client validates the chain up to a trusted root, verifies the server's signature over the handshake transcript, and confirms the certificate matches the requested domain.
The shared secret is expanded via HKDF into separate keys for client-to-server and server-to-client traffic. From this point, all data is encrypted with AES-GCM or ChaCha20-Poly1305.
Step through the TLS 1.3 handshake to see where ECDH key exchange and authentication fit together. Real P-256 keys are generated at each step.
After the handshake, the ephemeral ECDH keys are deleted. The shared secret is expanded into multiple keys using HKDF: separate keys for the handshake phase and the application data phase, separate keys for each direction. This key separation ensures that compromising one set of keys does not affect the others.
The handshake establishes the secure channel. The record protocol is how data actually flows through it. Every byte of application data is fragmented into records, each independently encrypted with AEAD using a unique nonce derived from the record's sequence number.
Type a message and watch it get fragmented, encrypted, and packaged into TLS records. Try tampering with one.
Each TLS record is an AEAD operation: the plaintext fragment is the message, the record header is associated data, and the sequence number constructs the nonce. The sequence number also prevents replay and reordering attacks. An attacker who captures and replays a record will use the wrong sequence number, and decryption will fail.
If a server's private key is compromised tomorrow, can an attacker decrypt traffic they recorded today? With ephemeral key exchange, the answer is no. Each connection generates fresh ECDH keys that are deleted after the handshake. TLS 1.3 makes this mandatory.
What happens when a server's private key is compromised? It depends on how the session key was established.
Certificates have expiry dates. But sometimes you need to revoke trust before a certificate expires: a private key gets compromised, a domain changes ownership. And sometimes a CA itself misbehaves. The ecosystem needs mechanisms to undo trust and hold CAs accountable.
CRLs (Certificate Revocation Lists)
The CA publishes a list of revoked serial numbers. Browsers download and check it. The lists get large, and downloading them adds latency. Most browsers stopped checking CRLs because of performance issues.
OCSP (Online Certificate Status Protocol)
Instead of downloading the whole list, the browser asks the CA “is this specific certificate revoked?” in real time. This leaks which sites you visit to the CA. If the OCSP responder is down, browsers typically soft-fail and treat the certificate as valid, which defeats the purpose.
OCSP Stapling
The server itself queries the OCSP responder periodically and staples the signed response to the TLS handshake. The browser gets proof of non-revocation without contacting the CA. This solves both the privacy and availability problems.
Short-lived certificates
The pragmatic answer. Let's Encrypt certificates are valid for 90 days. If a key is compromised, the damage window is limited to the remaining validity period. Some proposals push for even shorter lifetimes, reducing the need for revocation infrastructure entirely.
Revocation handles compromised certificates. But what about compromised CAs? Certificate Transparency (CT) holds CAs accountable by requiring every issued certificate to be submitted to public, append-only logs. Domain owners can monitor these logs for unauthorized certificates.
CT has already proven its worth. In 2017, Google researchers used CT logs to discover that Symantec had misissued over 30,000 certificates. This led to the distrust of all Symantec-issued certificates, one of the largest CA incidents in history. Chrome now requires CT for all publicly trusted certificates.
CT logs publicly record every certificate issued by participating CAs. Domain owners monitor these logs to detect unauthorized certificates.
The protocols are well designed. Most real-world failures come from misconfiguration, expired certificates, and missing automation. These guidelines cover the most common mistakes and how to avoid them.
TLS 1.3 removes insecure algorithms, mandates forward secrecy, and completes the handshake in a single round trip. Disable TLS 1.0 and 1.1 entirely. If you still need TLS 1.2, restrict it to strong cipher suites only.
Manual certificate management leads to outages. Certificates expire, engineers forget to renew, and services go down. Use ACME with Let's Encrypt. Short-lived certificates (90 days or less) limit the damage window if a key is compromised.
Set up CT log monitoring for your domains. Services like crt.sh let you see every certificate issued for your domain. If a CA issues a certificate you did not request, you will know within hours.
Configure your server to staple OCSP responses to the TLS handshake. This gives clients proof of non-revocation without leaking browsing history to the CA. It also removes a round trip to the OCSP responder.
The server must send intermediate certificates alongside its own. Browsers have root certs preinstalled but not intermediates. Missing intermediates is one of the most common TLS configuration errors.
Use tools like SSL Labs (ssllabs.com/ssltest) to grade your TLS configuration. Check for weak ciphers, missing intermediates, expired certificates, and protocol version issues. Run these tests after every change.
The single most impactful thing you can do for certificate security is automation. Every major certificate-related outage (Equifax 2017, Microsoft Teams 2020, Spotify 2020) was caused by a certificate expiring because someone forgot to renew it. Machines do not forget.