Task: Your HTTPS Checklist And What's Next

You made it. Eighteen chapters. From the padlock lie to post-quantum cryptography. Let's pull everything together — what you can now do, and where the protocol goes from here.

What You've Earned

Looking back at where we started: a single sentence — "the padlock doesn't mean what you think" — opened into eighteen chapters of structured understanding. You can now:

• Explain what HTTPS actually guarantees to anyone, including a skeptical product manager;
• Read a cipher suite name like TLS_AES_256_GCM_SHA384 as a sentence;
• Walk through the TLS 1.3 handshake step by step and explain why it's a round trip faster than 1.2;
• Decode a certificate by its fields and chain, and understand why the chain matters;
• Identify the security properties of a config at a glance — PFS, AEAD, AEAD-only, modern protocols;
• Recognize the historical attacks that shaped modern best practices (Heartbleed, POODLE, BEAST, Lucky 13);
• Automate certificate issuance with Let's Encrypt and ACME;
• Harden a server using Mozilla's Intermediate or Modern profile;
• Debug TLS issues with openssl s_client, Wireshark, and SSL Labs;
• Understand what's coming — mTLS, QUIC, post-quantum cryptography.

That's not a small list. Most engineers black-box this entire layer of the internet. You don't anymore.

The Production HTTPS Checklist For 2026

A practical, copy-paste-able list of what a hardened public HTTPS deployment looks like in 2026. Print it. Pin it. Use it at code review time.

Protocols and Ciphers:

• TLS 1.3 enabled;
• TLS 1.2 enabled (still needed for some corporate clients);
• TLS 1.0, TLS 1.1, SSL 3.0 all disabled;
• Cipher list from Mozilla Intermediate (AEAD-only, no CBC, no RC4);
• ssl_prefer_server_ciphers off; (let clients optimize).

Certificates:

• Issued via ACME (Let's Encrypt or other ACME CA);
• Automated renewal (Certbot, acme.sh, Caddy, Traefik);
• SAN covers all hostnames you serve;
• ECDSA preferred where supported (smaller, faster);
• fullchain.pem deployed in the right order;
• Renewal alerts active — alert if cert expires in <14 days.

Transport-level hardening:

• OCSP Stapling on, with a working DNS resolver configured;
• Session tickets off unless you have key rotation;
• HSTS header with max-age=63072000; includeSubDomains; preload;
• Domain submitted to the HSTS preload list (only after testing!);
• HTTP/2 enabled, HTTP/3 enabled if your stack supports it.

Monitoring and validation:

• Run SSL Labs scan monthly on every public host;
• Run testssl.sh on internal hosts;
• Subscribe to Certificate Transparency alerts (crt.sh, Cert Spotter, Facebook CT Monitor);
• Alert on TLS handshake error spikes.

Bonus credit:

• ECH enabled if you're behind a supporting CDN;
• Post-quantum hybrid key exchange (ML-KEM) — already on by default at major CDNs;
• Migration plan for the 47-day cert lifetime hitting in 2029.

Hit these and you've eliminated the top two causes of HTTPS outages in production: expired certs (automation fixes it) and weak configs (Mozilla Intermediate fixes it).

What's Next — Three Trends To Watch

1. mTLS (Mutual TLS) For Service-To-Service Auth

Everything we've covered assumes the server authenticates to the client. In mTLS, the client also presents a certificate. The server validates the client's cert before accepting the connection. Both sides are authenticated cryptographically.

Why it matters in 2026:

• Service meshes like Istio, Linkerd, and Consul use mTLS by default to authenticate microservices to each other;
• Zero-trust networks replace VPN-style boundaries with mTLS-on-every-connection;
• Kubernetes-native auth in many platforms uses mTLS to identify pods;
• API security is shifting from "API keys in headers" to "client certs at the TLS layer."

mTLS uses the same TLS protocol you've already learned. The handshake is identical, plus a CertificateRequest message and a client certificate. If you understood Section 1's handshake, you understand mTLS.

2. QUIC And HTTP/3

The transport layer is changing under TLS. QUIC is a new transport protocol (RFC 9000) that runs over UDP instead of TCP, with TLS 1.3 baked directly into the protocol rather than layered on top. HTTP/3 (RFC 9114) is HTTP semantics over QUIC.

Why it matters:

• No head-of-line blocking — each request is its own QUIC stream, packet loss in one stream doesn't stall others;
• Faster connection setup — 1-RTT for new connections, 0-RTT for resumption;
• Connection migration — when a phone switches from Wi-Fi to cellular, the connection survives (the QUIC Connection ID isn't tied to IP);
• Encryption is built in — even transport-level metadata is encrypted, hard for middleboxes to inspect.

2026 adoption: HTTP/3 is at 30-35% of global web traffic as of Q1 2026. Cloudflare, Google, Meta, Akamai, Fastly all run it at scale. Browsers (Chrome, Firefox, Safari, Edge) all support it natively. Nginx added HTTP/3 to mainline in 2023. Caddy supports it out of the box.

If you've understood TLS 1.3, you've understood the cryptographic heart of QUIC. The new piece to learn is the transport-level part — multiplexed streams, congestion control, connection migration.

3. Post-Quantum Cryptography

We touched on this in Section 2's PFS chapter. The threat: a sufficiently advanced quantum computer could break RSA, ECDSA, and Diffie-Hellman by efficiently solving the math underneath them. Today's "encrypted" traffic that's been recorded and stored could be retroactively decrypted years from now.

The fix: post-quantum key exchange algorithms based on math problems (like lattice cryptography) that quantum computers can't efficiently solve.

The standard: ML-KEM (formerly known as Kyber), standardized by NIST in August 2024. Used in hybrid mode alongside classical ECDHE — both run simultaneously, and the shared secret mixes both. If either component holds, the connection is secure.

2026 deployment status:

• Cloudflare deployed hybrid X25519+ML-KEM by default for all domains in 2024;
• Chrome and Firefox ship hybrid PQ key exchange enabled by default;
• As of April 2026, ~52% of all TLS handshakes use a post-quantum-capable key exchange — a stunning rate of adoption;
• ML-KEM-768 is the most common choice — performance is roughly the same as classical ECDH.

If you run a public site behind a major CDN, you already have post-quantum protection. Without doing anything. That's how fast the migration moved.

What about signatures? ML-DSA (formerly Dilithium) is the post-quantum signature algorithm, also NIST-standardized. Deployment is slower because the signatures are larger and the cert ecosystem needs to be updated. Expect this to roll out gradually through 2027-2030.