← Blog

The TLS journey

Networking · Part 4 of 4 · Interactive · ~20 min, noob to hero

Networking series · Part 4 of 4

You type https:// a hundred times a day. A tiny padlock appears and you move on. This tutorial opens the padlock. We'll follow one certificate from birth (a key pair on a server), through a Certificate Authority, onto the server, and then watch a frontend use it to talk to a backend safely.

Words in plain English

Level 1 · Noob
The problem TLS solves

Your browser and a server talk through many strangers: Wi‑Fi, your ISP, a dozen routers. Plain HTTP is a postcard: anyone handling it can read or rewrite it. TLS (Transport Layer Security) makes three promises:

Two tools deliver these promises. Learn them and the rest is just choreography.

Tool 1: the key pair (asymmetric crypto)

A key pair is two mathematically linked keys. The public key is shared with everyone. The private key never leaves its owner. Two things you can do with them:

Signing is the star of this story: it's how a certificate becomes unforgeable. Asymmetric math is slow, though, so TLS uses it only for the introduction.

Tool 2: the session key (symmetric crypto)

One shared secret key that both sides use to lock and unlock data. It's super fast (AES / ChaCha20), but both parties must somehow already have the same key. That's the classic chicken-and-egg problem, and the handshake exists to solve it.

Level 2 · Apprentice
The journey in 11 steps

Click through. Part A happens once, when you set up a server. Part B is the one-time trust that's baked into your device. Parts C and D happen on every connection.

Level 3 · Pro
Play with the three trickiest ideas

Level 4 · Hero
Do it yourself

Make your own CA and certificate locally

You can replay the entire story on your laptop. This is exactly what tools like mkcert do.

# 1. Be a Certificate Authority: make a root key + self-signed root cert
openssl genrsa -out ca.key 4096
openssl req -x509 -new -key ca.key -days 3650 -subj "/CN=My Toy Root CA" -out ca.crt

# 2. Be the server: make a private key + a CSR for api.local
openssl ecparam -genkey -name prime256v1 -noout -out server.key
openssl req -new -key server.key -subj "/CN=api.local" \
  -addext "subjectAltName=DNS:api.local" -out server.csr

# 3. Be the CA again: sign the CSR
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 90 -copy_extensions copy -out server.crt

# 4. Look inside
openssl x509 -in server.crt -noout -text | less

# 5. Serve it and talk to it (add "127.0.0.1 api.local" to /etc/hosts)
openssl s_server -accept 8443 -cert server.crt -key server.key -www &
curl --cacert ca.crt https://api.local:8443/     # works: you trust your CA
curl https://api.local:8443/                       # fails: nobody else does

The last two lines are the whole lesson: the same certificate is valid or invalid depending purely on whether the client's trust store contains the issuer.

Install it on a real server

# Let's Encrypt does steps 1-5 of the journey for you:
sudo certbot --nginx -d api.example.com

# What it ends up wiring into nginx:
server {
  listen 443 ssl http2;
  server_name api.example.com;
  ssl_certificate     /etc/letsencrypt/live/api.example.com/fullchain.pem;  # your cert + the middle CA cert
  ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;    # never share this
  ssl_protocols       TLSv1.2 TLSv1.3;
}

Inspect a live handshake

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
curl -v https://example.com 2>&1 | grep -E "SSL|TLS|subject|issuer|expire"

Or open DevTools → Security (Chrome) to see the protocol, cipher and chain for the current page.

TLS 1.3 vs 1.2 and other hero details

• Fast. TLS 1.3 starts the secret-agreement in the very first message, so the handshake needs just one back-and-forth instead of two.
• Old recordings stay safe ("forward secrecy"). The secret for each connection is made from throwaway numbers that are deleted afterwards. So even if someone steals your server's private key next year, they can't unlock traffic they recorded today. The private key only signs; it never protects the data itself.
• Which site do you want? One server can host many sites. The first message includes the hostname you want (called SNI), so the server picks the right certificate.
• Which HTTP version? That same first message also agrees on HTTP/2 vs HTTP/1.1 (called ALPN).
• Cancelling a stolen cert ("revocation"). A CA can cancel a cert, but browsers don't always check. So certs are made short-lived (Let's Encrypt: 90 days) and auto-renewed.
• Two-way ID check (mTLS). The server can also demand an ID card from the client. Common between internal services.
• Public logbook. CAs publish every cert they issue to public logs, so if someone gets a fake cert for your domain, you can spot it.

Frontend → backend: where TLS actually lives

When your React app does fetch("https://api.example.com/users"), you write no TLS code. The browser's network stack performs steps 7–11 before the first byte of your request is sent; the server (or a reverse proxy / load balancer in front of it) terminates TLS and hands plain HTTP to your app code, usually over a private network.

Related things you'll meet: mixed content (an HTTPS page can't call an http:// API), CORS (unrelated to TLS, it's about which origins may read responses), and HSTS (a header telling browsers "never use plain HTTP for this site again").

Debugging cheat‑sheet

Check yourself

The map to keep

1. The server makes a key pair; the private key stays put.
2. A CA verifies the domain, then signs the public key + name into a certificate.
3. Your device ships with a list of roots it trusts; trust flows down the chain.
4. On connect, the server shows its cert and proves it owns the private key by signing the handshake.
5. Both sides derive a fresh shared secret that never crossed the wire.
6. Everything after that is fast symmetric encryption with tamper detection.

That's TLS. Everything else, from HTTP/3 to mTLS to service meshes, is a variation on this one idea.