When you visit a site over HTTPS, your browser and the server perform a cryptographic handshake in about 100 milliseconds. Here’s every step.

The problem HTTPS solves

HTTP sends everything in plain text. Anyone on the same network (coffee shop WiFi, your ISP, a compromised router) can read your passwords, cookies, and data. HTTPS encrypts the connection so only your browser and the server can read the traffic.

The TLS handshake (simplified)

Step 1: Client Hello

Your browser sends: “Hi, I want a secure connection. I support these encryption methods: [list]. Here’s a random number.”

Step 2: Server Hello

The server responds: “Let’s use this encryption method. Here’s my SSL certificate and another random number.”

Step 3: Certificate verification

Your browser checks the certificate:

• Is it signed by a trusted Certificate Authority (CA)?
• Is it expired?
• Does the domain name match?
• Is it revoked?

Your OS and browser ship with a list of ~150 trusted CAs. If the certificate chains back to one of them, it’s trusted.

Step 4: Key exchange

This is the clever part. Your browser and the server need to agree on an encryption key, but they can’t send it in plain text (someone might be watching).

They use Diffie-Hellman key exchange: both sides generate a shared secret by exchanging public values. Even if someone captures the entire exchange, they can’t compute the shared secret. The math makes it computationally impossible.

Step 5: Symmetric encryption begins

Both sides now have the same secret key. All further communication is encrypted with fast symmetric encryption (AES-256-GCM typically).

Why not use the certificate’s public key for everything? Because asymmetric encryption (RSA/ECDSA) is ~1000x slower than symmetric encryption (AES). The handshake uses asymmetric crypto once to establish a shared key, then switches to symmetric for speed.

The full timeline

Browser                          Server
   │                                │
   ├── Client Hello ───────────────>│  (1ms)
   │<──────────── Server Hello ─────┤  (1ms)
   │<──────────── Certificate ──────┤
   ├── Verify cert (local) ─────────│  (5ms)
   ├── Key Exchange ───────────────>│  (2ms)
   │<──────────── Key Exchange ─────┤  (2ms)
   ├── Finished ───────────────────>│  (1ms)
   │<──────────────── Finished ─────┤  (1ms)
   │                                │
   │  ═══ Encrypted connection ═══  │
   │                                │
   ├── GET /page (encrypted) ──────>│
   │<──── Response (encrypted) ─────┤

Total handshake: ~50-100ms. After that, encryption adds <1ms per request.

What the padlock icon means

The padlock in your browser means:

1. The connection is encrypted (nobody can read the traffic)
2. The server proved its identity via a certificate
3. The data hasn’t been tampered with (integrity check)

It does NOT mean:

• The website is safe or trustworthy
• The website won’t steal your data
• The website is legitimate (phishing sites can have HTTPS too)

Why Let’s Encrypt changed everything

Before 2015, SSL certificates cost $50-300/year. Let’s Encrypt made them free and automated. That’s why HTTPS went from ~30% of web traffic in 2015 to ~95% today.

# Get a free certificate
sudo certbot --nginx -d yourdomain.com
# Auto-renews every 90 days

Common HTTPS mistakes

Mixed content. Your page loads over HTTPS but includes an image or script over HTTP. The browser blocks it or shows a warning. Fix: use relative URLs or https:// everywhere.

Expired certificates. Let’s Encrypt certificates last 90 days. If auto-renewal breaks (server misconfiguration, DNS change), your site shows a scary “Not Secure” warning. Fix: set up a cron job or use certbot’s built-in timer, and monitor with a service like UptimeRobot.

Self-signed certificates in production. Self-signed certs work for local development but browsers don’t trust them. Users see a full-page warning. There’s no reason to use self-signed certs in production when Let’s Encrypt is free.

Not redirecting HTTP to HTTPS. If someone types http://yoursite.com, they should be automatically redirected to https://. Without this, some users browse your site unencrypted without knowing it.

server {
    listen 80;
    server_name yoursite.com;
    return 301 https://$server_name$request_uri;
}

TLS versions matter

TLS 1.0 and 1.1 are deprecated and have known vulnerabilities. Modern servers should only support TLS 1.2 and 1.3. TLS 1.3 is faster (one fewer round trip in the handshake) and more secure (removed weak cipher suites entirely).

You can check what your server supports at ssllabs.com/ssltest.

The one-sentence summary

HTTPS uses a brief asymmetric handshake to establish a shared secret, then encrypts everything with fast symmetric encryption — so your data is unreadable to anyone except your browser and the server.

Related: What is HTTPS? · SSL Certificate Expired — fix · SSL Handshake Failed — fix · How JWT Actually Works