Digital signatures, certificates, and TLS

The previous lesson left one question open: asymmetric encryption lets you send a secret to someone whose public key you have — but how do you know that public key actually belongs to them, and not to an attacker in between? Digital signatures and certificates answer that, and together they make TLS, the protocol behind every https:// address, possible.

Digital signatures: proof of origin, not secrecy

A digital signature runs asymmetric encryption in reverse. Instead of encrypting a message with someone’s public key so only they can read it, the sender signs a message with their own private key, and anyone can verify it using the sender’s public key. If the verification succeeds, two things are true: the message came from whoever holds that private key, and it was not altered afterwards — the same collision-resistance property from the previous lesson’s discussion of hashing is what makes tampering detectable. A signature proves authenticity and integrity; it does not, by itself, keep the message secret.

Certificates: a signature vouching for a public key

A digital certificate solves the “whose public key is this really” problem. As Cloudflare’s Learning Center explains, an SSL/TLS certificate is “a data file hosted in a website’s origin server” containing the domain name, the public key, an expiry date, and — critically — “the certificate authority’s digital signature.” A certificate authority (CA) is a trusted third party that checks a website controls the domain it is requesting a certificate for, then signs that certificate with its own private key. Your browser ships with a built-in list of CAs it trusts, so when it receives a certificate signed by one of them, it can trust the public key inside without ever having met the website’s operator. A self-signed certificate — one a site signs itself rather than getting from a CA — has no such outside vouching, which is why browsers treat one as untrustworthy by default.

TLS: putting both to work

RFC 8446, the specification for TLS 1.3, describes a handshake in phases: key exchange, in which the two sides establish shared secret material; then authentication, where, in the RFC’s words, “the server side of the channel is always authenticated; the client side is optionally authenticated” — normally only the website proves its identity, not the visitor. The server proves who it is using its certificate and a signature only it could produce with its private key. Once both sides trust the connection, they derive fast symmetric keys (the previous lesson’s AES, typically) for the actual data. RFC 8446 states plainly what this buys you: confidentiality and integrity for the data exchanged, and authentication of the server. It also states, just as plainly, a limit: “TLS does not hide the length of the data it transmits”, and metadata such as which server you connected to and when remains visible to anyone positioned to observe the connection.

What the padlock icon does and does not mean

A phishing site built on a lookalike domain can have a perfectly valid certificate: TLS authenticates the domain, not the intent of whoever registered it. This is why the earlier lesson on how attacks unfold treats a fake login page, padlock and all, as a live threat, not a contradiction.