What is an SSL certificate
Last lesson, we checked a signature with a public key. In key exchange and in public-key locking, the same assumption sat underneath every step: the public key in our hands really belongs to that person. If someone in the middle hands over their own public key as if it were that person's, both locking and signature checks end up matching the wrong party. On what grounds can we trust the public key of a site we have never seen before?
A fake public key can slip in
Until now we simply trusted the public keys we received and assumed each one was naturally that person's. But the story changes if someone sits between you and the other side. If that someone quietly hands over their own public key instead of the real one, you lock your secret with it without knowing, and they open it with their own private key. If they then lock it again with the real public key and pass it on, neither side notices.
The public key as a tool has no flaw. What wobbles is one thing only: whose key it is. This is exactly the homework the key exchange lesson left us.
Pick which public key gets sent. If the real one arrives intact it is safe; if it is swapped for a fake in the middle, you can see the secret open in the wrong hands.
Side by side, the difference is plain. When the real key arrives nothing goes wrong, but when a fake arrives, your screen still shows nothing more than one public key arriving. A public key is just a long number with no name tag, so looking at it alone cannot tell you who owns it.
So what you need is someone who vouches, in a way you can trust, that this public key really belongs to that person. The one who stands behind that promise comes next.
A trusted body vouches for it
Here a body everyone has agreed to trust appears: a certificate authority, or CA for short. A site submits its public key and domain name to a CA, and the CA checks that the applicant really controls that domain.
Once the check is done, the CA puts the public key, the domain name, the issuer, and a validity period into one document and signs it with its own private key, the same unforgeable signature from last lesson. A document carrying a CA's signature like this is a certificate. In effect, the public key now carries a trustworthy ID card.
Tap the issuing steps in order. The site submits its public key, and the CA checks it, signs it, and bundles everything into one certificate.
Now the public key no longer drifts alone; the CA's signature stands behind it. That signature can only be made with the CA's private key, so nobody can imitate it. Whoever receives the certificate checks the signature with the CA's public key, and if it holds, they can trust that the listed public key belongs to the listed domain.
A certificate also has a validity period, and one past it no longer counts as a guarantee. But one question remains: on what grounds do we trust that CA's public key?
The browser's trust list, PKI
The grounds for trusting a CA are simpler than you might expect. Operating systems and browsers ship with a list of root CA certificates that have been vetted in advance. That list is the starting point of trust.
Root CAs do not sign every site directly, though. A root CA's private key is usually kept offline and locked away, and day-to-day issuing is handled by intermediate CAs that the root has vouched for. So the browser starts from the site's certificate, climbs back through each signing CA one step at a time, and finishes when it reaches a root on its trust list. This whole structure, where vouching links to vouching, is called the public key infrastructure, or PKI.
Climb the chain one step at a time. Starting from the site's certificate and passing through the intermediate CA, verification ends when you reach a root CA on the trust list.
At the end of the chain we met the root CA the browser already trusted. A root certificate is signed by itself, so trust in it comes from the fact that it sits on the list. If the chain links up to there without a break, even the public key of the site at the very bottom becomes trustworthy.
You do not know the site personally, but you trust it because the root you trust vouched for the intermediate CA, and the intermediate CA vouched for the site. So when a real certificate arrives, what separates a pass from a warning?
A real certificate passes, a fake warns
When a browser receives a certificate, it checks several things in turn: whether the chain reaches a root on the trust list, whether every signature along the chain is valid, whether the domain written in the certificate matches the address you are visiting, and whether the validity period has not run out.
If everything holds, it passes and a padlock appears in the address bar. If even one thing fails, the browser puts up a large warning screen and stops the connection. This check is the gatekeeper that filters out fake public keys.
Verify the two certificates one at a time. The real one, which reaches the trust list, passes; the fake, signed by a place nobody trusts, raises a warning.
The real one passed quietly, and the fake was stopped by a warning at once. If you meet a warning screen like this on the web, it means you should not just click through, because it is telling you the site's public key has not been vouched for in a trustworthy way.
Meanwhile, if a site's private key leaks, the certificate becomes dangerous even while it is still valid. So a CA can revoke such a certificate, and there are mechanisms for checking revocation information too. Now let's sum up what a certificate protects.
Wrapping up
Put together, it goes like this. To use a public key safely, you must be able to trust that it really belongs to that person or site, because there are attacks that hand over a fake public key in the middle. So a trusted body, a CA, checks first and then signs one document containing the public key, the domain name, and the validity period; that document is a certificate.
A browser holds a list of root CAs in advance and traces a certificate's signatures back up the chain to see whether they reach that list. This whole connected web of trust is PKI.
Tap the four key points in order to review: the danger of a fake public key, the CA's signature and vouching, the chain up to the root, and pass or warn.
Now you know on what grounds we trust a public key we have never seen. A public key drifting alone could belong to anyone, but a certificate carrying a CA's vouching can be trusted. Behind the padlock you see in the address bar every day lie exactly this certificate and this chain of trust.
Locking, signing, and identity vouching: all the pieces are now in place. Next lesson, we see how they move together inside HTTPS at the moment you connect to a site.