How to Harden a TLS Configuration
A TLS endpoint that negotiates the wrong protocol or cipher quietly weakens every connection it serves. Hardening is about removing the dangerous options — old protocols, weak ciphers, compression, insecure renegotiation — and adding the defensive ones like HSTS and OCSP stapling, all without breaking the clients that actually need to reach you. This guide walks through each decision in order.
In plain words
Hardening a TLS configuration means restricting the server to safe protocols and ciphers and adding protective headers, and PlayCISO has a free, browser-based TLS Hardening Lab where you can test a config before you ship it. Allow only TLS 1.2 and 1.3, use AEAD cipher suites with forward secrecy, disable compression and insecure renegotiation, and turn on HSTS and OCSP stapling.
The practical trap is breaking a required client while tightening settings — so inventory your oldest clients first, roll changes out on staging, and watch handshake-failure rates before you enforce.
Step by step
- 1
Allow only TLS 1.2 and 1.3; disable SSLv3, TLS 1.0 and 1.1
SSLv3, TLS 1.0 and TLS 1.1 are deprecated (RFC 8996) and carry known weaknesses such as POODLE and BEAST. Set the minimum protocol to TLS 1.2 and enable TLS 1.3. In nginx use ssl_protocols TLSv1.2 TLSv1.3; in Apache SSLProtocol -all +TLSv1.2 +TLSv1.3. Prefer TLS 1.3 wherever the client base allows it, since it removes legacy ciphers and renegotiation entirely.
- 2
Select AEAD cipher suites with forward secrecy
Restrict ciphers to authenticated encryption (AEAD) suites that provide forward secrecy: ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Drop CBC-mode, RC4, 3DES and any suite using static RSA key exchange. For TLS 1.3 the suites are fixed and all safe; for TLS 1.2 set an explicit allow-list like ECDHE-ECDSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384.
- 3
Disable TLS compression and insecure renegotiation
TLS compression enables the CRIME attack, so turn it off (modern stacks disable it by default; verify it is not re-enabled). Ensure only secure (RFC 5746) renegotiation is permitted and disable client-initiated renegotiation to blunt renegotiation-based denial-of-service. TLS 1.3 removes renegotiation altogether, which is another reason to prefer it.
- 4
Use a strong key and certificate chain
Use at least a 2048-bit RSA key or a 256-bit ECDSA (P-256) key, signed with SHA-256 or better. Serve the full intermediate chain so clients do not have to fetch it, but never include the root. Keep the private key off world-readable paths and rotate the certificate before expiry. Automate issuance and renewal (for example with ACME) so an expired cert never causes an outage.
- 5
Enable HSTS to force HTTPS
Send Strict-Transport-Security to tell browsers to only ever connect over HTTPS, defeating SSL-stripping downgrade attacks. Start with a short max-age while you confirm everything on the domain works over HTTPS, then raise it (max-age=31536000; includeSubDomains). Only add the preload directive and submit to the preload list once you are certain every subdomain is HTTPS-ready, because removal is slow.
- 6
Turn on OCSP stapling
OCSP stapling lets your server attach a recent, signed revocation status to the handshake so clients do not have to contact the CA themselves — faster and more private. Enable it (nginx: ssl_stapling on; ssl_stapling_verify on; with a resolver and trusted chain) and confirm the stapled response appears in a handshake trace. Consider a must-staple certificate only after stapling is proven reliable.
- 7
Test without breaking required clients
Before enforcing, inventory the oldest clients and integrations that must keep working (legacy mobile apps, embedded devices, B2B partners). Scan the endpoint, review the negotiated protocol and cipher, and check for weak-protocol fallbacks. Roll out on a staging host first, watch handshake-failure and error rates after changing the live config, and keep a documented rollback ready.
Paste or build a TLS config, see which protocols and cipher suites it allows, and get a prioritized list of weaknesses to fix — free, in your browser.
Related
The full set of PlayCISO cryptography and PKI how-tos in one place.
Manage a key lifecycleGenerate, rotate and retire the keys and certificates behind your TLS endpoints.
All hands-on labsBrowser-based labs to practice the security skills in these guides.
All free toolsScanners, modelers and reference tools across the PlayCISO toolbox.
Frequently asked questions
Is it safe to drop TLS 1.0 and 1.1?
For almost all modern traffic, yes — every current browser and OS has supported TLS 1.2 for years, and the major browsers removed 1.0/1.1 support in 2020. The exception is legacy embedded devices or old B2B partners. Inventory those clients first, give them a migration deadline, and only keep an older protocol temporarily on an isolated endpoint if a critical integration genuinely cannot be upgraded.
What is the difference between TLS 1.2 and TLS 1.3 for hardening?
TLS 1.3 removes the dangerous options outright: it drops CBC ciphers, RSA key exchange, compression and renegotiation, and mandates forward secrecy. That means a TLS 1.3-only server is hardened almost by default. With TLS 1.2 you have to curate the cipher list yourself, because insecure suites are still available unless you explicitly disable them.
Do I still need to configure cipher suites if I enable TLS 1.3?
The TLS 1.3 cipher suites are a short fixed set and are all considered secure, so you do not need to prune them. You still configure TLS 1.2 ciphers for any client that falls back to 1.2. If you serve TLS 1.3 only, cipher selection is effectively solved, but curve and signature preferences still matter.
What does OCSP stapling actually buy me?
It moves the certificate-revocation check from the client to your server. The server fetches a signed status from the CA periodically and staples it into the handshake, so the client learns the cert is not revoked without making its own call to the CA. That is faster for users and avoids leaking which sites a visitor is browsing to the CA.
Can HSTS lock me out of my own site?
It can cause pain if you enable HTTPS incorrectly or let a certificate expire, because browsers will refuse to connect over plain HTTP and will not let users click through a certificate warning. Start with a small max-age, verify every path and subdomain works over HTTPS, then increase it. Treat the preload list as a one-way door and only submit when you are certain.
How often should I re-test a TLS configuration?
Re-test after every change to the web server, load balancer or certificate, and on a recurring schedule — at least quarterly — because new attacks and deprecations arrive over time. Automated scanning on each deploy catches regressions where a config change silently re-enables a weak protocol or cipher.