TLS Certificates Chronicles

3 min readJan 31, 2025

(You Don’t Need to Be a Cryptographer to Get It)

Picture this: You’re logging into your bank account. A hacker is lurking, rubbing their hands like a cartoon villain. But TLS certificates swoop in like a superhero — except instead of a cape, it wears Math 😁.

Let’s decode how this works, no PhD required.

The Problem with Secret Handshakes

(Or: Why Symmetric Encryption is Like a Risky Text Message)

You know when you share a Netflix password with a friend via text? If a hacker intercepts it, game over. Symmetric encryption has the same flaw:

  • Same key locks and unlocks data.
  • The Catch: Sharing that key online is like yelling your Wi-Fi password in a coffee shop.

Your analogy:

“Imagine mailing a locked diary to a friend but having to ship the key separately. A thief could steal both!”

Asymmetric Encryption to the Rescue

(Or: How Padlocks and Keys Saved the Internet)

Meet public and private keys — the tag team:

  • Public Key = Padlock 🔒 (Share it with everyone).
  • Private Key = Master Key 🔑 (Guard it like your phone passcode).

How it works:

  1. Server sends you its padlock (public key).
  2. You lock your data with 🔒.
  3. Only the server’s 🔑 can unlock it.

SSH Example:

ssh-keygen  # Your laptop screams: "I’M MAKING KEYS!"  
cat ~/.ssh/authorized_keys # Server says: "Add your padlock here"

The TLS Handshake (Not the Boring Kind)

(Or: How Your Browser and Server Become BFFs)

Here’s the secret handshake behind every “HTTPS” you see:

  1. Server sends a certificate (its ID card) with its public key.
  2. Browser checks if the ID is legit (more on this later!).
  3. Browser creates a symmetric key, locks it with the server’s public key, and sends it.
  4. Server unlocks it with its private key.
  5. Boom! Now they chat securely using the symmetric key.

Why the switch?

  • Asymmetric encryption = Slow for big data (like Math homework).
  • Symmetric encryption = Fast (like TikTok scrolling).

Certificates — The Internet’s Fake ID Detector

(Or: Why Hackers Can’t Just Print Their Own Diplomas)

A certificate is like a driver’s license for servers. It says:

  • “I’m www.your-bank.com, I swear!”
  • “Signed: Trusted CA” (Certificate Authority).

Hacker Fails:
If a hacker tries to fake a certificate:

  1. Their “CA” isn’t in your browser’s trusted list.
  2. Your browser throws a 🔥 “Not Secure” meltdown.

How to Get a Certificate:

  1. Generate a CSR (Certificate Signing Request):
openssl req -new -key my-bank.key -out my-bank.csr -subj "/CN=mybank.com"

2. CA (like Let’s Encrypt) verifies you own mybank.com.

3. CA signs your CSR like a notary stamping a document.

Tip: Self-signed certs are like making your own ID — it works for testing, but browsers side-eye them.

When Servers Ask for Your ID (mTLS)

(Or: How Banks Double-Check It’s Really You)

Sometimes servers need to verify clients too. Enter Mutual TLS (mTLS):

  • You get a certificate (like an employee badge).
  • Server demands it before letting you in.
  • Used in ATMs, VPNs, and paranoid APIs.

The Big Picture: PKI

Public Key Infrastructure (PKI) is the behind-the-scenes bouncer managing:

  • Who gets certificates.
  • Which ones get revoked (like blocking a lost credit card).

Your Homework: Click the padlock 🔒 in your browser’s URL bar. See that certificate? Now you know what it’s doing there!

Got questions? Found a typo? Call me out in the comments!

--

--

Saurabh Yadav
Saurabh Yadav

Written by Saurabh Yadav

👨‍💻 SRE at @infracloudio 🔧 | A curious Networking 🕸️ and Observability 🔬 enthusiast.

No responses yet