You see the padlock icon 🔒 in your browser every day. I realised I didn't actually know what it represented, beyond "it's secure".
This is the simple, straight-to-the-point explanation I wish I'd had.
The Problem: Shouting in a Crowded Room
Before we had the padlock, we had HTTP. Using HTTP is like sending your password on a postcard. Anyone who intercepts the mail can read it. It's just plain text.
This opens the door for a Man-in-the-Middle (MITM) attack, where someone sits between you and, for instance, your bank, listening in or even pretending to be the bank.
HTTPS (the 'S' is for Secure) solves this. It has two jobs:
- Encrypt the traffic so no one can read it.
- Verify you're talking to the real server, not an imposter.
This post is about the second job: verification.
The Solution: Digital ID Cards
To prove who you are online, you need a system. The one we use is built on a clever bit of maths called asymmetric encryption.
You don't need to understand the algorithms, just the concept:
- Public Key: Think of this as an open padlock. You can give it to anyone. They can use it to lock a message, but they can't use it to unlock anything.
- Private Key: This is the only key that can open the padlock. You keep it completely secret on your server.
You also need to know about something called a Digital Certificate. This is just a file that staples your public key to your identity (e.g., www.google.com). It's a digital ID card.
The Players in the Trust Game
So a server has a digital ID card. Who cares? I can make a fake ID card that says I'm www.your-bank.co.uk, right?. This is where the trust system comes in.
Certificate Authority (CA)
This is the 'Passport Office' of the internet. It's a company (like Let's Encrypt or DigiCert) whose entire job is to verify that a person or company who requests a certificate for www.example.com actually owns that domain. If they do, the CA uses its own private key to 'sign' the server's certificate, acting as a stamp of approval.
Root CA & The Chain of Trust
This is the final piece of the puzzle. How do we trust the CA?
Your browser and operating system don't trust websites directly. They come with a pre-installed list of globally trusted organisations called Root CAs.
The system works like this:
- A Root CA (the ultimate source of trust, like the Government) issues a certificate to an Intermediate CA (like a regional Passport Office).
- That Intermediate CA then issues and signs your website's Server Certificate (your passport).
When your browser sees a server certificate, it checks the signature. It sees it was signed by an Intermediate CA. It then checks that certificate, and sees it was signed by a Root CA. Since the Root CA is already in its trusted list, the browser knows the entire chain is valid and displays the padlock icon.
Okay, So What Have We Learned?
When it comes to security, our browsers don't just take a website at its word. They demand to see a valid ID—an ID that has been approved and signed all the way up a 'chain of trust' to an authority it already knows is legitimate.
We know why we need this (to stop imposters) and we know who the players are.
In the next post, we'll look at the TLS Handshake – the step-by-step conversation your browser has with a server to actually check this ID card and start a secure conversation.
sam