How HTTPS Works: TLS, Certificates, and Encryption Explained for Developers

HTTPS is on every website, but most developers treat it as a magic checkbox. Understanding TLS — the handshake, certificate chains, symmetric and asymmetric encryption, and forward secrecy — is not just academic. It directly affects how you configure servers, diagnose SSL errors, understand certificate pinning, and recognize security vulnerabilities. This guide explains the full picture.

⚡ TL;DR: HTTPS = HTTP over TLS. TLS uses asymmetric encryption (RSA/ECDH) to establish a shared secret, then symmetric encryption (AES) for bulk data. Certificates prove server identity via chain of trust to root CA. TLS 1.3 does this in 1 round trip instead of 2.

The TLS 1.3 handshake — step by step

# TLS 1.3 Handshake (1 round trip — 2x faster than TLS 1.2)

# Step 1: Client Hello
# Client sends:
# - TLS version: 1.3
# - Supported cipher suites: [TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256]
# - Key share: client's Diffie-Hellman public key (anticipating server choice)
# - Random: 32 bytes of randomness

# Step 2: Server Hello + Certificate + Finished
# Server sends (all in one flight):
# - Selected cipher: TLS_AES_256_GCM_SHA384
# - Key share: server's DH public key
# - Certificate: server's public key + domain name + CA signature
# - Certificate Verify: proves server owns the private key
# - Finished: MAC over entire handshake
# Server can NOW derive the session key and start encrypting

# Key exchange (ECDHE — Elliptic Curve Diffie-Hellman Ephemeral):
# client_private * server_public = server_private * client_public = shared_secret
# This math is the magic — both compute SAME secret without transmitting it
# Shared secret → session key → all subsequent data encrypted with AES

# Step 3: Client Finished
# Client: derives same session key, verifies server's MAC, sends Finished
# Connection established. All data: AES-GCM encrypted with session key

Symmetric vs asymmetric encryption

# Asymmetric (RSA, ECDSA): different keys to encrypt and decrypt
# Public key: encrypt OR verify signatures (share freely)
# Private key: decrypt OR create signatures (NEVER share)
# Problem: slow — 1000x slower than symmetric
# Use for: key exchange, digital signatures, certificates

# Symmetric (AES-256-GCM): same key to encrypt and decrypt
# Problem: how do two parties agree on the key securely?
# Answer: use asymmetric to establish the symmetric key (DH key exchange)
# Use for: bulk data encryption (fast)

# Why TLS uses both:
# ECDHE: asymmetric key exchange → establishes shared AES key
# AES-GCM: symmetric encryption of all HTTP data
# Best of both: secure key exchange + fast bulk encryption

# Forward secrecy (ECDHE):
# Each session uses fresh ephemeral keys
# Even if server's private key is compromised LATER
# Past sessions CANNOT be decrypted (no long-term private key used)
# Compare: RSA key exchange (no FS) — past sessions decryptable if key stolen

Certificate chains and trust

# Certificate chain: leaf → intermediate → root CA

# Your server certificate (leaf):
# Subject: cheatcoders.net
# Public key: [your server's public key]
# Signed by: Let's Encrypt R3 (intermediate)
# Valid: 2026-04-01 to 2026-07-01 (90 days)

# Intermediate CA certificate:
# Subject: Let's Encrypt R3
# Signed by: ISRG Root X1 (root)

# Root CA certificate:
# Subject: ISRG Root X1
# Signed by: itself (self-signed)
# Trusted by: OS/browser certificate store (pre-installed)

# Verification chain:
# Browser has ISRG Root X1 in trust store
# ISRG Root X1 vouches for Let's Encrypt R3
# Let's Encrypt R3 vouches for cheatcoders.net
# ∴ Browser trusts cheatcoders.net

# HSTS (HTTP Strict Transport Security):
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
# Browser: for 1 year, ALWAYS use HTTPS for this domain
# Even if user types http:// — browser upgrades to https:// locally
# Prevents SSL stripping attacks

Common TLS misconfigurations

• ❌ TLS 1.0/1.1 enabled — both have known vulnerabilities. TLS 1.2 minimum, TLS 1.3 preferred.
• ❌ Weak cipher suites — RC4, DES, 3DES are broken. Use AES-GCM, ChaCha20-Poly1305 only.
• ❌ Missing intermediate certificate — server sends only leaf cert. Mobile apps fail silently.
• ❌ Certificate not renewed — Let’s Encrypt expires every 90 days. Automate with certbot.
• ❌ Mixed content — HTTPS page loading HTTP resources. Blocks on modern browsers.
• ✅ Test with: testssl.sh your-domain.com or ssllabs.com/ssltest
• ✅ Enable HSTS after verifying HTTPS works completely
• ✅ Use ECDSA certificates (smaller, faster) over RSA where possible

TLS knowledge is essential for the AWS S3 presigned URL security guide — understanding TLS termination and certificate validation is foundational for cloud security. External reference: Illustrated TLS 1.3.