Is this public key really theirs, certificates

A fake public key can slip in

Until now we just trusted a public key and used it.
We assumed a public key we received was naturally that person's.
But there is a gap right here.
What if someone sits between me and the other side?
If that someone quietly hands over their own public key
instead of the real one,
I do not know and end up believing it is genuine.
Then the secret I locked
opens for the wrong person.
The public key itself is fine,
but whose it is becomes shaky.

Tap the public key being sent. If the real one arrives intact it is safe, but if a swapped fake arrives you can notice the danger.

You saw the difference between the two cases.
If the real one arrives intact, there is no problem.
But if it is swapped for a fake,
I had no way to notice on my own.
Looking at a public key alone,
I cannot tell whether it is the true owner's.
A public key carries no name tag.
So what is needed is clear.
Something that vouches, in a trustworthy way,
that this public key really belongs to that person.
Next we see who provides that vouching.

A trusted body vouches for it

Here a body everyone trusts appears.
A certificate authority, CA for short.
A site brings its public key to the CA.
The CA checks that it really is that site's,
and vouches like this.
This public key truly belongs to this site.
And it attaches a signature to that vouching, with its own private key.
That very signature that cannot be forged.
The public key, the site name, and the CA's signature,
bundled together in this document, is exactly a certificate.
In effect, a trustworthy identity tag is attached to the public key.

Tap the issuing steps in order. The CA checks the site's public key, attaches its signature to the vouching, and bundles it into a certificate.

Now the public key no longer drifts alone.
It carries the vouching of the CA's signature on its back.
The key point is that the signature cannot be forged.
Only the CA holds the CA's private key.
So whoever receives the certificate
can check that signature with the CA's public key.
If the signature holds, the vouching is genuine,
and the public key really is that named site's.
But here one more thing snags us.
How do we trust that CA in turn?
Next we follow the chain of trust.

The browser's trust list, PKI

The grounds for trusting a CA are surprisingly simple.
A browser already carries, from the start,
a list of the CAs it trusts.
This list is the starting point of trust.
When a site sends a certificate,
the browser looks at the CA that signed it.
If that CA was in turn vouched for by a higher CA,
it climbs one step up at a time.
Climbing like that,
when it reaches a CA on the trust list,
the chain connects to trust and verification ends.
This whole structure, where vouching links to vouching,
is called the public key infrastructure, PKI.

Climb the chain one step at a time. Starting from the site's certificate, when it reaches a CA the browser trusts, verification completes.

Climbing the chain,
we finally reached the starting point of trust.
That CA the browser trusts in advance.
If the chain links up to there without a break,
then even the public key of the site at the very bottom
becomes something you can trust.
It is a structure where vouching holds up vouching.
Even if I do not know the site directly,
I trust it because a CA I trust vouched for it.
Then, when a certificate actually arrives,
what decides between passing and a warning?
Next we compare that verification.

A real certificate passes, a fake warns

When the browser receives a certificate,
it calmly weighs two things.
First, whether the signing CA reaches the trust list.
And whether that signature actually matches.
If both hold, the certificate passes.
A lock mark appears in the address bar,
and you can exchange secrets with peace of mind.
Conversely, if a place not on the trust list signed it,
or the signature is off, or the site name does not match,
the browser raises a large warning.
This verification is the gatekeeper that filters out fake public keys.

Compare the two certificates. A real one that reaches the trust list passes, while a fake signed by an untrusted place raises a warning.

The real certificate passed quietly.
The fake was blocked at once by a warning.
That warning is exactly the signal protecting us.
If you meet a big warning screen while using the web,
it means do not just ignore it and click through.
It is a notice that the site's public key
has not been vouched for in a trustworthy way.
The danger of the fake public key from the first step
is exactly what this verification blocks.
Now it is clear what a certificate protects.
Next we wrap up the whole thing at once.

Let's wrap up

Gathered on one line, it is this.
To use a public key safely,
you must be able to trust it really belongs to that person.
Because handing over a fake public key in the middle is dangerous.
So a trusted body, a CA,
vouches by signing that this public key truly belongs to this site.
That vouching document is a certificate.
A browser holds a list of trusted CAs in advance,
and verifies a certificate by tracing it up to that list.
If the vouching holds, it passes; if it is off, a warning.
And this whole web of trust is PKI.

Tap the key points in order to review. (fake public key danger -> CA signs to vouch -> trace up to the trust list -> pass or warn)

Now you know what we trust to judge
whether a public key really belongs to that person.
A public key drifting alone is shaky,
but a certificate carrying a CA's vouching can be trusted.
Behind the lock mark we see in the address bar every day
lie exactly this certificate and chain of trust.
When the several pieces of cryptography gather like this,
they can form one genuinely secure connection.
Locking, signing, and identity vouching are woven together.
Next, let's look at how these pieces work together
in an actual connection.