Upgrade to TLS 1.3 with safe ciphers

TLS 1.3 is faster and more secure. This guide shows how to enable it, disable legacy versions, and pick sane cipher suites without breaking older clients.

Why upgrade

TLS 1.3 reduces handshake round trips, removes dangerous ciphers, and improves defaults. It’s widely supported by modern browsers and improves both security and performance.

Compatibility quick facts

• Modern browsers, iOS 12+/Android 10+, OpenSSL 1.1.1+, and recent Java runtimes support TLS 1.3
• Keep TLS 1.2 enabled for legacy clients during rollout, then review client error logs before tightening further

Server configuration

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# Consider OCSP stapling for faster and more reliable revocation checks
ssl_stapling on;
ssl_stapling_verify on;
# resolver 1.1.1.1 8.8.8.8; # set a trusted resolver for stapling verification

Apache

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
SSLHonorCipherOrder off
SSLSessionTickets off

IIS

• Enable TLS 1.2/1.3 via registry or Group Policy on supported Windows Server versions
• Prefer modern cipher suites, and disable RC4/3DES

CDN/edge

1. Cloudflare: enable TLS 1.3 and modern cipher suites, and set minimum TLS to 1.2
2. AWS CloudFront: use a Security Policy that includes TLS 1.2/1.3, and enable HTTP/2/3 as needed

HTTP/2 and HTTP/3

• Enable HTTP/2 alongside TLS 1.3 for better multiplexing and performance
• If your platform supports HTTP/3/QUIC, pilot it on a subset of routes or via the CDN first

Disable legacy versions safely

• Audit traffic to see if TLS 1.0/1.1 are still used
• Communicate TLS deprecation timelines to relevant partners
• Disable in staging first, then production during a low-traffic window

Strong defaults that hold up over time

• Prefer these TLS 1.3 cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256
• Keep resumption safe: use short‑lived tickets or rotate keys regularly, and avoid long‑lived session tickets across many servers
• Enable OCSP stapling so the server provides certificate revocation status to clients, and keep the certificate chain complete with up‑to‑date intermediate certificates
• Use a modern certificate authority workflow (ACME) with automatic renewal and post‑renewal verification

Testing and validation

• Track over time with automated checks and alert when origin or edge regresses
• Barrion TLS/SSL Security Checker (automated): validate protocol version, cipher suites, and HSTS across origin and edge
• SSL Labs server test (target an A or A+)
• openssl s_client -tls1_3 -connect example.com:443 -servername example.com
• Browser DevTools → Security to confirm protocol and cipher
• nmap --script ssl-enum-ciphers -p 443 example.com to see offered suites and protocols

Common mistakes

• Forcing a single cipher, instead of letting the client and server negotiate between modern choices
• Not enabling HTTP/2 negotiation (ALPN) on the load balancer or reverse proxy, which can make browsers fall back to HTTP/1.1
• Leaving TLS session tickets enabled without rotating keys, which creates long‑lived resumption keys. Use short‑lived tickets or rotate keys regularly.
• Disabling TLS 1.2 before measuring impact, remove only after logs confirm no meaningful breakage
• Missing OCSP stapling or serving an incomplete certificate chain

Advanced tips

• Prefer CHACHA20 on devices without AES acceleration, otherwise AES‑GCM is fine
• Use Mozilla SSL Configuration Generator as a reference
• If using a CDN, configure TLS at the edge and keep origin modern too

Troubleshooting common errors

• Handshake failure after change: confirm SNI and ALPN are enabled on the terminator, and verify the certificate chain with openssl s_client -connect host:443 -servername host -showcerts
• Some clients cannot connect: inspect logs for protocol mismatches, and temporarily re‑enable TLS 1.2 while you identify affected user agents
• A+ not reached in SSL Labs: check OCSP stapling, intermediate chain completeness, HSTS, and whether weak fallback ciphers are accidentally offered

Rollout plan you can trust

1. Turn on TLS 1.3 in staging and validate that certificate configuration is correct with Barrion, SSL Labs or openssl
2. Enable TLS 1.3 in production with TLS 1.2 kept on, and monitor error rates and client mix
3. Rotate session ticket keys and verify OCSP stapling and chain health
4. After two to four weeks with no issues, consider tightening legacy protocol support

Pair this with HSTS from the HTTPS implementation guide and review header hygiene in the Security headers guide.

Conclusion

Enable TLS 1.3, keep 1.2 for compatibility, remove older versions, and use a small set of modern, safe ciphers. Test thoroughly and monitor continuously.

Validate your deployment and keep an eye on regressions in the Barrion dashboard. For a quick verification, use the TLS/SSL Security Checker.