This article briefly explains certificate authorities in terms of public/private keys, since I really didn’t get it until now.

• Public key cryptography is a wonderful concept. It rests on the idea of a hard-to-reverse mathematical function. With this hard-to-reverse function, you can create two keys: a public key and a private key. With the public key, you can encrypt a message in a way that can only be decrypted by the private key. Therefore, to establish a secure communication channel with someone, you just hand them your public key.
• Before public key cryptography, both parties had to agree on a secret key to encrypt/decrypt. Because public key cryptography is asymmetric, you can hand everyone the same public key in order for them to talk secretly to you, without any of them being able to read what another one told you.
• On the web, however, that creates a problem: for every hostname we visit, how do we get its public key in a way we can trust? The server could just send it, but an attacker in the middle could swap it, and we have no secure channel to check it against yet.
• Certificate authorities (CAs) solve this.
• A CA is also a pair of public/private keys. The public keys of CAs come preinstalled in your browser.
• Each CA uses its private key to sign a certificate for each hostname: a statement that says “the public key of this hostname is X.”
• The owner of each hostname chooses which CA to get its certificate from. The certificate names the CA that signed it, so your browser knows which CA public key to check it with.
• For example, when you get a certificate from Let’s Encrypt (a CA), it first checks that you control the hostname, by asking you to place a token on your website or in your DNS records. Once that’s verified, you send it your public key, and it sends you back a certificate signed with its private key: “the public key of this hostname is X.” Your private key never leaves your server.
• When you connect to a hostname, the server sends you its certificate. Your browser checks the signature with the CA’s public key, which it already has, and checks that the certificate’s hostname is the one you’re visiting. If both check out, you can trust that X is the hostname’s real public key.
• So instead of trusting a public key for every hostname, you only need to trust a few CA public keys, which came with your browser.
• An attacker in the middle could send you a different key, but they can’t produce a valid CA signature for it, so your browser would reject it.
• You may ask: how is this verification of a signature done? Signing is encryption in reverse! To encrypt, you use someone’s public key, and only their private key can undo it. To sign, you use your own private key, and anyone can undo it with your public key. If the result matches the original statement, only the holder of the private key could have produced it.