Whose key is it?

The situation

You open your laptop in a café and log in to your bank over the café’s Wi-Fi. Someone else on that network could answer your browser before the bank does, with their own public key.

Your browser would then run a flawless key exchange and encrypt everything perfectly, with the wrong party. What stops this?

What is going on

The impostor in the middle

The attack in the situation is called a man-in-the-middle attack. The attacker runs one key exchange with you and another with the bank, and passes messages between them. Both connections are encrypted. The attacker reads everything.

Lessons 2 and 3 gave us encryption and signatures. Both depend on one thing: having the right public key. Encryption alone never tells you who is on the other end.

For a few people, you can compare fingerprints over a channel you already trust, for example by reading them out on a call. SSH asks you to do roughly this the first time you connect to a new server. It does not scale to the web.

A certificate binds a key to a name

A certificate is a signed statement: “this public key belongs to this name”. It is signed by an issuer, usually a certificate authority (CA), that your device already trusts, directly or through a chain (lesson 6). The format used on the web is X.509, profiled for the internet in RFC 5280.

Swipe sideways to see the whole diagram.

The main fields:

• Subject and Subject Alternative Name (SAN): the names the certificate is for, such as shop.example.
• Public key: the subject’s public key.
• Issuer: who signed it.
• Validity: “not before” and “not after” dates.
• Serial number: unique for each certificate from that issuer.
• Extensions: what the certificate may be used for, and whether it may issue other certificates (lesson 5).
• Signature: the issuer’s signature over everything above.

Because the issuer signed it, changing any field breaks the signature. Your browser checks that signature with the issuer’s public key, checks that the name matches the site and that today is between the two dates, and only then accepts the public key inside.

What a certificate is not

A certificate is public. The server hands it to anyone who connects. It contains no private key, it is not encrypted, and it does not encrypt anything itself.

That is why copying it is useless to an impostor. During the connection the server must also prove it holds the private key that matches the public key in the certificate, by signing part of the handshake (lesson 7). The café attacker can copy the bank’s certificate but cannot make that signature.

Try it

Try it: Certificate decoderOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

Read this sample certificate field by field: the names, the issuer, the two validity dates, the serial number, the public key and the signature. Look for a private key: there is none.

Check

Check yourself

An attacker on café Wi-Fi copies your bank's real certificate and presents it to your browser. Why does the connection still fail?

1. The attacker cannot prove they hold the private key matching the public key in the certificate
2. Certificates are encrypted, so the copy is unreadable
3. A certificate only works from one IP address

Show answer

Answer A The attacker cannot prove they hold the private key matching the public key in the certificate

What happened

The browser asks the server to sign part of the handshake with the matching private key. The attacker does not have it, so the check fails.

Why

A certificate is public by design; anyone can copy it. What proves identity is possession of the private key, which only the real bank holds.

The rule

A certificate alone proves nothing. The holder must prove possession of the matching private key.

Check yourself

Which of these is inside a certificate?

1. The owner's private key
2. The subject's names and public key, the issuer, validity dates, a serial number, extensions and the issuer's signature
3. The key that encrypts the web traffic

Show answer

Answer B The subject's names and public key, the issuer, validity dates, a serial number, extensions and the issuer's signature

What happened

A certificate holds a public key, names, the issuer, dates, a serial number, extensions and the issuer's signature.

Why

Its job is to bind a public key to a name, signed by someone you trust. Private keys never go in it, and traffic keys are agreed separately in the handshake.

The rule

A certificate is public: it binds a public key to a name and never contains a private key.

Check yourself

A laptop's clock is set two years in the future. What happens when it visits a normal HTTPS site?

1. Nothing; certificates do not depend on the clock
2. The connection silently becomes unencrypted
3. The browser reports the site's certificate as expired

Show answer

Answer C The browser reports the site's certificate as expired

What happened

The browser compares the certificate's 'not after' date with its own clock and decides the certificate has expired.

Why

Validity checks use the device's local time. If that time is wrong, perfectly good certificates fail.

The rule

Certificate validity depends on the client's clock; when many sites fail at once on one device, check its date and time first.

Takeaways

• Encryption without identity can be a private line to an impostor.
• A certificate is a signed statement, from an issuer your device trusts, that binds a public key to a name. It is public and holds no private key.
• The server proves it is the real owner by using the matching private key during the connection.

Go further

• Handbook: Whose key is it? Binding identity to keys
• Handbook: Anatomy of an X.509 certificate
• Next lesson: Names, jobs and asking for a certificate

In the gameLevel 7: The impostorThe Town Gate, Keystone. In development