You see the padlock icon 🔒 in the address bar of 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
That padlock icon 🔒 means your browser is communicating with the website using HTTPS. Before that was standard, the web mostly ran on its less-secure sibling, HTTP.
HTTP stands for Hypertext Transfer Protocol. Think of it as the fundamental language that web browsers and servers use to request and send files like web pages and images. The problem? It's a language spoken out in the open. Using HTTP is like sending your password on a postcard—anyone who intercepts the mail can read the contents in plain text.
This vulnerability opens the door for a Man-in-the-Middle (MITM) attack, where a malicious actor sits between you and, for instance, your bank. They can listen in or even alter the conversation, 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.
The name sounds complicated, but the idea is simple. With asymmetric encryption, the encryption keys come in a matched pair, but they have opposite jobs. One key can only lock the data, and only its unique partner key can unlock it.
You don't need to understand the algorithms, just this concept:
- Public Key: This is the locking key. Think of it as an open padlock 🔏. You can give it to anyone. They can use it to lock a message, but that same key can't be used to open it again.
- Private Key: This is the unlocking key. It is the only key that can open the padlock. You must 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