Certificate Authorities and the Chain of Trust

When your browser connects to your bank's site, it needs the bank's real public key, not one planted by an attacker. It can't just trust the key because the site says so. Instead it checks a digital certificate: a file signed by a certificate authority (CA), stating 'this public key belongs to this bank.' Your browser already has a built-in list of root CAs it trusts completely. If the certificate traces back to one of those roots, the browser accepts the key and encrypts the connection with it.

That tracing-back is the chain of trust. A root CA rarely signs certificates for websites directly. Instead it vouches for intermediate CAs, and those intermediates vouch for individual sites. Each certificate is signed by the authority one level up, so following the signatures upward eventually lands on a root your browser already trusts. This layering means a root's trust fans out to huge numbers of sites: if a root vouches for 50 intermediates and each of those vouches for 200 sites, 10,000 sites ultimately depend on that one root staying honest. That's also the danger. If a root CA is compromised, every certificate beneath it, through every intermediate, becomes suspect, because the signatures all point back to a root that can no longer be trusted.

This is why the padlock icon in your address bar only ever confirms an encrypted connection. It proves the data between you and the server is scrambled during transit, matching the key from a valid certificate. It says nothing about who runs that server. A scammer can obtain a legitimate certificate for a fake site and show the same padlock, because the CA only verifies key ownership, not business honesty.