The padlock in the address bar

You did everything right. You opened a secure connection, the data is scrambled, an eavesdropper at the next table sees only noise. And you typed your bank password straight to a thief. Encryption kept the line private — but private to whom? If you scramble a chat with an impostor, you have kept your secret perfectly safe all the way into the wrong hands. That is the gap encryption alone leaves open. Closing it is the quiet second job of the little padlock in your address bar.

Encryption keeps it private. It does not say who is listening.

The last item gave you encryption: scramble the data so anyone reading the wire gets gibberish. That solves eavesdropping. It does nothing about impersonation — the other danger from item seven, where an attacker pretends to be your bank.

Think about what a scrambled line guarantees. It guarantees that only the two ends can read what flows between them. It says nothing about which two ends. A perfectly encrypted conversation with a fake site is still a conversation with a fake site. The lock is on, the secret is safe, and the secret goes to the impostor.

So a secure web connection needs two things, not one. HTTPS — the “S” stands for secure — does both. First it encrypts the line (item eight). Second it proves identity: it checks the site is really who it claims to be. This item is about that second job.

The certificate: a signed ID card

When your browser connects to a site, the site hands over a certificate — a small digital file that works like an ID card. It says, in effect, “I am your-bank.example,” and it is signed (the signatures from item eight) by a Certificate Authority, or CA: a trusted third party whose job is to vouch for who owns which web address.

Here is the part that matters. Your browser does not trust the site. It has never met the site. What it trusts is the CA. Your browser ships with a built-in list of CAs it already trusts — the way a bouncer trusts a government, not the stranger holding the ID. The stranger’s card is only worth anything because a vouched-for authority signed it.

A signature, recall, cannot be faked or copied onto a different document without the authority’s secret key. So a certificate signed by a real CA is hard evidence: this authority I trust has confirmed this site owns this name.

The three checks, run in a blink

Every time you load a secure page, your browser quietly runs three checks on the certificate. All three must pass.

1. Is it signed by an authority I trust? Does the signature trace back to a CA in my built-in list? If a self-made certificate signs itself, or a CA I have never heard of signs it, this fails.
2. Is it for the exact name in the address bar? The certificate names a site. Does that name match what I typed — character for character? A certificate for your-bank.example does not match your-bank-secure.example. Close is not a match.
3. Is it still valid? Certificates expire, and a CA can revoke one early if it was issued in error or stolen. An expired or revoked card is no card.

Pass all three and you get the padlock — connection trusted. Fail any one and you get the big red warning page. This is exactly how impersonation from item seven gets caught: a fake site cannot get a real CA to sign a certificate for a name it does not own.

The trap: a padlock is not a promise of honesty

Now the part most people get wrong, and the reason this matters for the rest of the course.

The padlock proves two narrow things: the line is private, and the site really owns that exact web address. It does not prove the site is honest, safe, or who you assumed. A scammer can register secure-yourbank-login.example, get a perfectly valid certificate for it — because they really do own that address — and show you a green padlock all day long.

So the padlock answers one question: “Am I really talking to whoever owns this exact address?” That is only useful if you actually read the address. The padlock cannot read it for you. The real defence against a look-alike site is not the lock — it is checking the domain name with your own eyes.

A worked example: three sites, same browser

Watch the three checks decide.

The real bank. You go to your-bank.example. The certificate is signed by a CA your browser trusts — check one passes. It is issued for your-bank.example, matching the bar exactly — check two passes. It has not expired — check three passes. Padlock. Connection trusted. Everything worked.

The look-alike. A phishing email sends you to secure-yourbank-login.example. The page is a flawless copy. The line is encrypted. There is a padlock. But look at the certificate: it is valid, signed, current — and issued for secure-yourbank-login.example, because that is the address the scammer genuinely owns. Check one passes. Check three passes. Check two is the one that should stop you — the name in the bar is not your bank. Your browser shows no warning, because nothing is technically wrong; the connection is private to its real owner. The only thing standing between you and the thief is whether you read the name.

The expired site. You reach the right your-bank.example, but the certificate lapsed last week and nobody renewed it. Check three fails. Red warning page, before you can type a thing.

Three sites. The first two both show a padlock. The difference between safe and robbed is the name.

On the whole

Trust online is a chain of vouching. You trust your browser. Your browser trusts a handful of authorities. An authority vouches for a site. None of these parties has met you, and you have met none of them — you are taking the last seat in a line of strangers confirming each other.

That chain does most of the work invisibly, and it is genuinely strong. But it ends at you. The machine can confirm that a site is really whoever owns its address; it cannot know whether that address is the one you meant. You are the last link, and the one nobody else can replace. The padlock is the chain reaching your seat. Reading the name is the part that is yours.