TLS Configuration Best Practices for Public Web Servers

A solid TLS configuration for a public web server enables TLS 1.2 and 1.3, disables older protocols, uses modern cipher suites, automates certificate renewal, redirects HTTP to HTTPS, and adds HSTS once everything works. Most of the benefit comes from a few choices: current protocol versions, trusted certificates that never expire unnoticed, and regular testing. Defaults in recent server software are usually reasonable, but they should still be reviewed.

Which Protocol Versions Should You Enable?

TLS 1.3 is the current version and offers faster handshakes and a simpler, safer design, with legacy features removed. TLS 1.2 remains widely used and is still acceptable when configured with strong cipher suites. Older protocol versions, including SSL 3.0, TLS 1.0, and TLS 1.1, have known weaknesses and have been deprecated by browser vendors and standards bodies.

For most public sites, enabling TLS 1.2 and 1.3 and disabling everything older is the right baseline. Before dropping a version, check your traffic and your clients. Some legacy devices and embedded systems cannot use modern protocols, and compliance frameworks may have their own requirements.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

The example uses Nginx syntax, and equivalent settings exist in other servers. Directive behavior varies by version, so verify against the documentation of your server.

How Should You Choose Cipher Suites?

Cipher suite choices matter most for TLS 1.2, since TLS 1.3 has a small fixed set of strong suites. For TLS 1.2, prefer suites with forward secrecy, using ephemeral key exchange, and authenticated encryption such as AES-GCM or ChaCha20-Poly1305. Avoid suites based on RC4, 3DES, export-grade ciphers, and CBC modes where possible.

Rather than inventing your own list, start from a maintained recommendation. Several well-known configuration generators and security guidelines publish current profiles, labeled by compatibility level, such as modern and intermediate. Pick the profile that matches your client base, and revisit it periodically, since recommendations change as weaknesses are found.

• Prefer forward secrecy so that a future key compromise cannot decrypt recorded traffic.
• Use ECDSA or RSA certificates with adequate key sizes, following current guidance.
• Do not hand-tune cipher lists without testing against your actual clients.

How Do You Manage Certificates Reliably?

Expired certificates cause many outages. Automate issuance and renewal using a protocol such as ACME, with a client that renews well before expiry and reloads the server. Monitor expiration dates independently, so a failed renewal alerts you with time to fix it.

• Serve the complete certificate chain, including intermediates, so clients can validate the certificate.
• Protect private keys with strict file permissions, and avoid copying them between systems unnecessarily.
• Consider OCSP stapling to speed up revocation checks, and check how your server and certificate authority support it.
• Use separate certificates for separate services where practical, to limit the impact of a key compromise.
• Understand certificate transparency logs, which let you detect certificates issued for your domains.

Short certificate lifetimes limit damage from key compromise, and automation makes them practical.

What Else Completes the Setup?

Redirect all HTTP traffic to HTTPS, and then enable HSTS so browsers connect securely from the start. Test with a short HSTS duration first, because a mistake is hard to undo once browsers have cached the policy.

Also avoid mixed content, where a secure page loads insecure resources, and keep server software updated, because many TLS issues are fixed through patches to libraries.

• Test your configuration with a reputable scanning tool, and re-test after changes.
• Review protocol and cipher settings at least once or twice a year.
• Terminate TLS at a well-maintained layer, and encrypt traffic behind it where the risk justifies it.
• Keep an inventory of certificates and who owns them.

Frequently Asked Questions

Is TLS 1.2 still safe to use?

Yes, with strong cipher suites and forward secrecy. Support TLS 1.3 alongside it and disable older versions.

Should I disable TLS 1.0 and 1.1?

Yes for public sites, unless a specific, documented legacy requirement exists.

How often should certificates be renewed?

Automate renewal well before expiry. Short lifetimes with automation are a good practice.

Does HSTS replace redirects?

No. You still redirect HTTP to HTTPS. HSTS makes browsers skip HTTP on later visits.

Summary

Enable TLS 1.2 and 1.3, use forward secret cipher suites, automate certificates, add HSTS carefully, and test regularly. Follow current recommendations from your server and certificate authority documentation.