TLS Configuration Security: The Practical Hardening Guide for Web Servers

TLS is where application security meets the network, and the gap lives in configuration. A server that negotiates TLS 1.0, offers legacy CBC suites, or serves a stale certificate is not "mostly secure" — it is providing downgrade paths. Mozilla's SSL Configuration Generator does the cipher-suite math; the controls below are the decisions around it.

1. Enforce a Floor: TLS 1.2 Minimum, TLS 1.3 Preferred

Disable TLS 1.0 and 1.1 unconditionally — they negotiate predictable IVs and CBC padding oracles. Modern clients support TLS 1.2 everywhere; serve TLS 1.3 first, fall back to 1.2, and treat anything below 1.2 as an error condition.

2. Offer AEAD Cipher Suites — Drop Everything Else

With TLS 1.2, restrict to AEAD suites (ECDHE-ECDSA-AES128-GCM-SHA256 and siblings per the Mozilla generator). Kill RC4, 3DES, DES, export ciphers, and anonymous DH. CBC mode is the single biggest source of historical TLS breakage — remove it where clients allow.

3. HTTP Strict Transport Security (HSTS)

Serve Strict-Transport-Security: max-age=31536000; includeSubDomains (add preload only if you control every subdomain, because preload is a one-way door). HSTS protects the next connection from downgrade and SSL-stripping, which is exactly the attack path plaintext misconfigurations invite.

4. Certificate Hygiene: Lifetime, Automation, and Expiry Alarms

Certificates expire, and the expiry is silent. Run ACME automation with a 60–90 day validity window, monitor remaining days with an alert at 14 days, and rotate automations on failure. A stale certificate is a live, unauthenticated trust bypass — browsers will prompt, users will click through, attackers will celebrate.

5. Session Tickets: Randomize per Server

Session resumption tickets should be unique per machine or sealed. When a server shares one ticket key across an estate, one compromised node resurrects old sessions fleet-wide. Prefer short ticket lifetimes and rotate keys.

A Certificate Rollover That Cannot Fail

Plan the order of moves carefully. Enable TLS 1.3 and HSTS first, since those changes are backward compatible and immediately raise the floor. Then restrict cipher suites to the Mozilla modern profile in staging and watch client handshake telemetry for a week before production. Finally, schedule the OCSP stapling verification and the session-ticket key rotation for the same maintenance window, so a certificate incident never coincides with unrelated configuration churn.

Verifying with testssl.sh

Testing beats reading logs. The testssl.sh tool enumerates protocol surface, cipher-suite selection, certificate chain integrity, and HSTS behavior in a report a browser cannot produce. Run testssl before every production change, compare against the Mozilla modern profile, and keep results in the change record. Legacy suites surface in production far more often than teams expect, and the only reliable way to catch them is an automated scheduled scan — a TLS finding you discover costs a sprint; one an attacker discovers costs the board.

What Reviewers See

A TLS review does not stop at "HTTPS is on". It checks protocol surface, suite selection against Mozilla's modern profile, HSTS posture, certificate lifetime and automation, and OCSP stapling where offered. Each finding gets a severity based on the concrete downgrade or plaintext path it enables.

Sources

• Mozilla SSL Configuration Generator
• OWASP Transport Layer Protection Cheat Sheet
• Let's Encrypt Certificate Validity