Configuring HTTPS/TLS correctly in 2026

Getting TLS right is no longer about "having a padlock." In 2026 a defensible HTTPS deployment means removing legacy protocol versions, pinning yourself to modern cipher suites with forward secrecy, and pairing the transport layer with the HTTP security headers that stop downgrade and mixed-content attacks. This guide follows the Mozilla Server Side TLS recommendations and NIST SP 800-52 Rev. 2, and is written to be copied into a real hardening ticket.

Drop TLS 1.0 and 1.1 — and most of TLS 1.2's baggage

TLS 1.0 and 1.1 have been formally deprecated by RFC 8996 since 2021. They rely on MD5/SHA-1 constructions in the PRF and permit cipher suites (RC4, CBC with implicit IVs) vulnerable to BEAST, POODLE (CVE-2014-3566) and Lucky 13. PCI DSS has forbidden them for years, and every major browser removed support in 2020. There is no compatibility argument left worth the risk: any client that cannot do TLS 1.2 cannot do modern web crypto at all.

Your baseline should be TLS 1.2 as the minimum and TLS 1.3 preferred. NIST SP 800-52r2 requires servers to support TLS 1.2 and recommends supporting TLS 1.3. Mozilla's "Intermediate" profile targets exactly this pair; the "Modern" profile is TLS 1.3 only and is appropriate when you control your client base (internal APIs, mobile apps).

Prefer TLS 1.3

TLS 1.3 (RFC 8446) is not a minor revision — it removes the entire class of insecure options. Static RSA key exchange is gone, so forward secrecy is mandatory. Renegotiation, compression (killing CRIME) and the legacy CBC-mode suites are removed. The handshake is one round trip (1-RTT), with optional 0-RTT for resumption, and most of it is encrypted. The permitted AEAD suites are effectively TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. If you do nothing else, enabling TLS 1.3 gives you the single biggest security uplift.

Forward secrecy and cipher selection

On TLS 1.2 you must explicitly choose ephemeral key exchange: prefer ECDHE (curve X25519 or secp256r1) with AES-GCM or ChaCha20-Poly1305. Disable static RSA, all CBC suites where practical, and anything with RC4, 3DES, or export-grade parameters. Forward secrecy guarantees that a future compromise of your server's private key cannot decrypt yesterday's captured traffic — a direct mitigation for "harvest now, decrypt later" adversaries.

• Certificates: ECDSA P-256 keys are smaller and faster than RSA-2048; serve both if you need broad compatibility.
• Key size: RSA 2048-bit minimum, ECDSA 256-bit minimum, per NIST 800-52r2.
• Curves: offer X25519 first, then secp256r1.

HSTS and preloading

HTTP Strict Transport Security (RFC 6797) tells browsers to only ever connect over HTTPS, defeating SSL-stripping man-in-the-middle attacks such as those launched with sslstrip. A production header looks like:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Use a two-year max-age. Add includeSubDomains only once you are certain every subdomain serves HTTPS, because it is absolute. The preload token, combined with submission to hstspreload.org, bakes your domain into the browser's hardcoded HSTS list, protecting even the very first visit. Preload is effectively permanent and slow to reverse, so treat it as a one-way door and test thoroughly first.

OCSP stapling

Certificate revocation checking traditionally leaks the sites a user visits to the CA and adds latency. OCSP stapling (the TLS Certificate Status Request extension) has the server fetch and cache a CA-signed, time-stamped OCSP response and attach it to the handshake. The client gets fresh revocation proof with no side connection. Enable it (ssl_stapling on in nginx) and pair it with OCSP Must-Staple on the certificate if your CA supports it, which turns a missing staple into a hard failure and closes the soft-fail gap that made classic OCSP nearly useless.

Eliminate mixed content

An HTTPS page that loads a script, stylesheet or iframe over HTTP is active mixed content — browsers block it, and rightly so, because it reintroduces the exact injection risk HTTPS removed. Passive mixed content (images, media) is blocked or auto-upgraded. Fix it at the source, then enforce it:

• Content-Security-Policy: upgrade-insecure-requests rewrites http:// subresource URLs to https:// automatically.
• Add block-all-mixed-content as a hard backstop for anything that cannot be upgraded.

The headers that finish the job

TLS secures the pipe; these headers secure what flows through it. A minimal hardened set:

• Content-Security-Policy — your primary defense against XSS (OWASP A03:2021 – Injection). Start with a report-only policy, then enforce a nonce/hash-based script policy.
• X-Content-Type-Options: nosniff — stops MIME-type sniffing.
• Referrer-Policy: strict-origin-when-cross-origin — stops leaking full URLs cross-site.
• Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy — isolate your browsing context and mitigate Spectre-class side channels.
• Set the Secure and HttpOnly flags plus SameSite on every session cookie.

Note that X-Frame-Options is now superseded by CSP's frame-ancestors directive for clickjacking defense; ship both during migration.

Verify, don't assume

Configuration drifts. Validate every change against SSL Labs' Server Test (aim for A+), Mozilla's Observatory, and testssl.sh in CI. Confirm your protocol floor with nmap --script ssl-enum-ciphers. Map results back to OWASP ASVS V9 (Communications) so the evidence lands in your audit trail. TLS is a control you can measure precisely — so measure it, on a schedule, and alert on regression.