TLS — Transport Layer Security — is the protocol that puts the "S" in HTTPS. When your browser shows a padlock, TLS is negotiating a secure channel between your machine and the server before any application data is exchanged. SSL was the predecessor; the name "SSL" persists in conversation but SSL 2.0 and 3.0 are long deprecated. Everything in 2026 runs TLS 1.2 at minimum, and TLS 1.3 should be your floor.
What changed in 2026
- TLS 1.3 is the only acceptable version. TLS 1.0 and 1.1 have been disabled by all major browsers since 2020. TLS 1.2 is still broadly supported but its weaker cipher suites are increasingly blocked by compliance scanners.
- Certificate lifetimes are now capped at 90 days. Apple's CA/Browser Forum proposal passed: as of March 2026, publicly trusted certificates max out at 90-day validity. ACME automation is no longer optional.
- Post-quantum cryptography shipped. Chrome and Firefox both default to hybrid key exchange (X25519Kyber768 — classical ECDH plus ML-KEM-768) to protect against "harvest now, decrypt later" attacks by future quantum computers.
- QUIC / HTTP/3 uses TLS 1.3 internally. The TLS handshake is embedded inside the QUIC protocol, completing in 0-RTT on resumed connections.
How the TLS 1.3 handshake works
Client Server
|── ClientHello (key_share, ciphers) ──→ |
|← ServerHello + Certificate + Finished ─|
|── Finished ──────────────────────────→ |
|═══════════ Encrypted data ═══════════ |
TLS 1.3 does this in 1 round-trip (1-RTT). The client includes its key share in the first message, so the server can derive the shared secret immediately and send its certificate and Finished message together. TLS 1.2 required 2-RTT.
On a resumed session (session ticket), TLS 1.3 supports 0-RTT early data — the client can send application data with the first message. The tradeoff is that 0-RTT data is not replay-protected; only use it for idempotent requests.
Certificate anatomy
A TLS certificate is an X.509 document containing:
- Subject — the domain(s) it is valid for (CN + SANs)
- Issuer — the Certificate Authority that signed it
- Public key — the server's asymmetric public key
- Validity period — notBefore and notAfter timestamps
- Signature — CA's digital signature over the above
# Inspect a live certificate
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -text | grep -A2 "Subject:\|Validity\|Subject Alternative"
Certificate types
| Type |
Validation |
Use case |
| DV (Domain Validation) |
Proves domain control only |
Most sites; free via Let's Encrypt |
| OV (Organization Validation) |
Proves org identity |
Corporate sites |
| EV (Extended Validation) |
Full legal entity verification |
Financial institutions |
| Wildcard |
Covers *.example.com |
Multi-subdomain deployments |
| Multi-SAN |
Multiple distinct domains on one cert |
SaaS with many domains |
For most developers in 2026, a DV cert from Let's Encrypt (free, 90-day, auto-renewed) is the right choice.
ACME automation
ACME (Automated Certificate Management Environment) is the protocol Let's Encrypt standardized. Your server proves domain control via HTTP-01 or DNS-01 challenge, and the CA issues a certificate automatically.
# Certbot standalone (for a server not yet serving HTTPS)
certbot certonly --standalone -d example.com -d www.example.com
# Certbot with Nginx (auto-configures and renews)
certbot --nginx -d example.com
# cert-manager in Kubernetes (ClusterIssuer resource)
kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: ops@example.com
privateKeySecretRef:
name: letsencrypt-prod
solvers:
- http01:
ingress:
class: nginx
EOF
Caddy handles ACME entirely automatically with zero configuration — it obtains and renews certificates for every domain in its config.
Cipher suites in TLS 1.3
TLS 1.3 reduced the cipher suite list to three, eliminating all the weak options that existed in TLS 1.2:
| Cipher suite |
AEAD |
Hash |
| TLS_AES_256_GCM_SHA384 |
AES-256-GCM |
SHA-384 |
| TLS_AES_128_GCM_SHA256 |
AES-128-GCM |
SHA-256 |
| TLS_CHACHA20_POLY1305_SHA256 |
ChaCha20-Poly1305 |
SHA-256 |
All three are considered secure in 2026. ChaCha20-Poly1305 is preferred on mobile where hardware AES acceleration is absent.
How to pick your TLS configuration
- Minimum TLS version: 1.2, but prefer enforcing TLS 1.3 only for internal services where you control both sides.
- Automate certificates with ACME (Certbot, cert-manager, Caddy, or your CDN/load balancer).
- Enable HSTS with a long max-age (1–2 years) and include subdomains once you are confident all properties serve HTTPS.
- Set OCSP stapling on your server so clients do not need to make a separate revocation check.
- Test with SSL Labs (ssllabs.com/ssltest) — aim for A+.
Common mistakes
Not automating renewal. A 90-day cert that expires causes immediate downtime. Certificate expiry is one of the most preventable outages.
Using a self-signed cert in production. Browsers show scary warnings. Users leave. Even internal services should use a private CA or Let's Encrypt.
Forgetting HSTS preloading. Without HSTS, a user's first visit over HTTP is vulnerable to downgrade attacks. Submit to the HSTS preload list for maximum protection.
Mixing TLS 1.2 and 1.3 without understanding cipher suite overlap. If you allow TLS 1.2, also disable weak ciphers like RC4, 3DES, and all _NULL_ suites explicitly.
Ignoring certificate transparency logs. CT logs are public; monitor them (e.g., via crt.sh) so you know when someone issues a cert for your domain.
What to skip
- Rolling your own crypto — use a well-maintained TLS library (OpenSSL, BoringSSL, rustls). Cryptography is an area where bespoke code reliably fails.
- Extended Validation certs for most use cases — browsers removed the EV green bar years ago; the UX benefit is gone.
- Pinning certificates in long-lived apps — certificate pinning causes catastrophic breakage when certs rotate; use public key pinning sparingly and only with a backup pin.
FAQ
What is the difference between SSL and TLS?
SSL 2.0 and 3.0 were the original protocol. TLS 1.0 was the rename/redesign in 1999. Both SSL versions are broken and disabled everywhere. When people say "SSL" they almost always mean TLS.
Does TLS protect against a compromised CA?
Partially. Certificate Transparency (CT) logs and CAA DNS records help detect misissuance, but they do not prevent it in real-time. DNSSEC + CAA + CT monitoring is the defense-in-depth approach.
What is mutual TLS (mTLS)?
In standard TLS only the server presents a certificate. In mTLS the client presents one too, authenticating both sides. This is common in service meshes (Istio, Linkerd) and zero-trust network architectures.
How does post-quantum TLS work?
The key exchange phase uses a hybrid algorithm: classical X25519 ECDH plus ML-KEM-768 (formerly Kyber). Both secrets are combined; an attacker needs to break both to recover the session key.
Where to go next