Programming

When Bob sets up an HTTPS web site (call it bob.com), he creates a public/private key pair, and has the public key signed by a certificate authority (CA) such as Let's Encrypt, generating a public key certificate. The certificate says that this key was signed for bob.com on a particular date.

Before issuing the certificate, the CA verifies that Bob is actually in charge of bob.com. This is important! They can do this, for instance, by asking Bob to put a particular file on the bob.com server, in a place that's publicly accessible. This proves that Bob actually has control over the bob.com domain.

Bob then puts the key pair and certificate into his web server configuration. Neither the CA, nor anyone else but Bob, have access to the private key; it only lives on Bob's servers.

When Alice's browser connects to bob.com it gets the public key certificate, and can check that it was signed by a trusted CA. If Earl injects a different public key, it won't be signed to bob.com and so Alice's browser will reject it. And without access to Bob's actual private key, Earl can't eavesdrop on the session.

If the CA is corrupt or incompetent, and issues bob.com certificates to people other than Bob (such as Earl), that's a problem! That has been a problem before. There have been CAs that have been "cancelled" for issuing wrong certificates; they are no longer trusted by browsers. Major web companies have put together Certificate Transparency to keep a public log of what certificates have been seen on the web, which makes it possible to at least notice if someone other than Bob is generating certificates that say they're for bob.com.