The entire internet’s security hinges on a surprisingly small number of entities that most people have never heard of.
Let’s see what this looks like in practice. Imagine you’re trying to connect to www.example.com. Your browser first asks www.example.com for its TLS certificate. This certificate is like an ID card, claiming "I am www.example.com, and here’s my public key." But how do you know this ID card is legitimate and not some imposter?
This is where Certificate Authorities (CAs) come in. Your browser has a pre-installed list of "trusted root certificates" – these are the digital signatures of the CAs themselves. When www.example.com presents its certificate, your browser checks if it’s signed by a CA it trusts. If the signature matches, and the certificate is valid (not expired, and for the correct domain), your browser trusts that the public key in the certificate truly belongs to www.example.com. With this verified public key, your browser can then securely encrypt the rest of its communication with the server.
Here’s a simplified view of the trust chain, often called a "chain of trust":
- End-Entity Certificate: This is the certificate for
www.example.com. It contains the server’s public key and is signed by an Intermediate CA. - Intermediate CA Certificate: This certificate is issued by a Root CA. It acts as a vouch for the End-Entity Certificate. It’s also signed by a Root CA.
- Root CA Certificate: This is the self-signed certificate of a trusted CA. Your operating system or browser comes with a built-in list of these trusted root certificates.
When your browser receives www.example.com’s certificate, it looks at the "Issued By" field. Let’s say it says "Intermediate CA X." Your browser then checks its list of trusted roots. If it finds a Root CA that has signed the certificate of "Intermediate CA X," and "Intermediate CA X" has signed www.example.com’s certificate, the chain is complete and trust is established.
The problem CAs solve is the "man-in-the-middle" attack. Without them, an attacker could intercept your connection to www.example.com, present their own fake certificate, and your browser would have no way to know it’s talking to an imposter. The CA’s signature on the certificate provides that verifiable proof of identity.
Here’s a bit of actual configuration you might see on a web server. This is a snippet from an Apache configuration file (httpd.conf or a virtual host file) that specifies the certificate and its private key:
SSLCertificateFile /etc/ssl/certs/www.example.com.crt
SSLCertificateKeyFile /etc/ssl/private/www.example.com.key
SSLCertificateChainFile /etc/ssl/certs/intermediate_ca.crt
The SSLCertificateFile points to the server’s certificate (the end-entity certificate). SSLCertificateKeyFile points to the corresponding private key, which must be kept secret. SSLCertificateChainFile points to the intermediate CA certificate that signed the server’s certificate. If this chain file is missing or incorrect, browsers might show a "certificate not trusted" warning, even if the main certificate is valid.
The most surprising thing is that the trust isn’t inherent to the certificate itself; it’s entirely a social and political construct. CAs are essentially trusted third parties whose reputation and security practices are relied upon by operating system vendors and browser developers. If a CA is compromised or misbehaves (e.g., issues certificates to fraudulent domains), the entire trust model can be undermined, leading to widespread revocation of trust for that CA.
The next concept you’ll likely encounter is Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP), which are mechanisms for checking if a certificate has been revoked before its expiry date.