The most surprising thing about Public Key Infrastructure (PKI) is that your browser doesn’t actually trust websites directly; it trusts a small, curated list of Certificate Authorities (CAs) that vouch for those websites.
Imagine you’re trying to send a secret message to your friend Alice. You can’t just write it down because Bob might intercept it. So, you give Alice a special box with a padlock. She puts her message in the box and locks it. Now, even if Bob intercepts the box, he can’t open it because he doesn’t have the key. Only Alice, who has the key, can unlock the box and read the message. This is the essence of asymmetric cryptography: a public key (the padlock) to encrypt and a private key (the key to unlock) to decrypt.
Now, how do you know that the padlock you’re using actually belongs to Alice and not Bob trying to trick you? This is where Certificate Authorities (CAs) come in. A CA is a trusted third party that verifies the identity of an entity (like a website owner) and then issues a digital certificate. This certificate acts like a digital ID card, containing the entity’s public key and information about their identity, all digitally signed by the CA.
When your browser connects to a website, say example.com, example.com presents its digital certificate. Your browser then checks this certificate. First, it verifies the CA’s signature on the certificate. This is where the "trust chain" comes into play. Your browser has a pre-installed list of "root CAs" that it inherently trusts. If the CA that signed example.com’s certificate is directly signed by one of these root CAs, the chain is short and strong. If not, it checks the CA that signed the first CA, and so on, up the chain, until it either reaches a trusted root CA or it doesn’t.
Here’s a simplified look at a typical certificate chain, as you might see it in your browser’s developer tools (usually under the "Security" tab):
- Leaf Certificate: This is the certificate issued to
example.com. It containsexample.com’s public key and identity details. - Intermediate Certificate(s): One or more certificates that link the leaf certificate to a root CA. The intermediate CA signed
example.com’s certificate, and a higher-level intermediate CA (or the root CA) signed the intermediate CA’s certificate. - Root Certificate: This is the self-signed certificate of a highly trusted CA (e.g., Let’s Encrypt, DigiCert, GlobalSign). Your operating system or browser trusts these implicitly.
When your browser receives example.com’s certificate, it essentially performs the following checks:
- Signature Verification: It uses the public key of the issuing CA (found in the intermediate certificate) to verify the digital signature on
example.com’s leaf certificate. If the signature is valid, it means the certificate hasn’t been tampered with and was indeed issued by that CA. - Trust Chain Validation: It then takes the intermediate certificate and checks its signature using the public key of its issuing CA (which could be another intermediate CA or a root CA). This process continues up the chain until it reaches a root CA that is present in the browser’s trusted store.
- Expiration: It checks if the certificate (and any intermediate certificates) has expired.
- Revocation: It can optionally check if the certificate has been revoked by the CA (e.g., if the private key was compromised) using protocols like OCSP (Online Certificate Status Protocol) or CRLs (Certificate Revocation Lists).
If all these checks pass, your browser establishes a secure HTTPS connection with example.com, encrypting all communication between you and the website.
The process of validating a certificate chain involves a recursive cryptographic verification. Each certificate in the chain (except the root) is signed by the private key of the entity identified in the next certificate up the chain. Your browser uses the public key of that next entity to verify the signature. This creates a chain of trust, where the trust in the leaf certificate ultimately relies on the trust in the root certificate.
The next concept you’ll likely encounter is how to manage and issue these certificates yourself for internal networks, often involving self-signed certificates or setting up your own internal Certificate Authority.