SSL/TLS Best Practices for Web Applications in 2026

Every web application should use HTTPS. That battle is won. But having an SSL certificate installed doesn't mean your TLS configuration is secure. There's a meaningful difference between "HTTPS works" and "HTTPS is configured properly."

Weak protocol versions, outdated cipher suites, short key lengths, and missing HSTS headers are all issues that a valid certificate won't protect you from. Here's how to get TLS right.

Protocol versions: what to support

TLS has gone through several versions. Not all of them are safe to use.

TLS 1.3: the current standard. It's faster (fewer round trips for the handshake), more secure (removed vulnerable cipher suites and compression), and should be your primary protocol. All modern browsers support it.

TLS 1.2: still acceptable and widely used. Many APIs and older clients only support TLS 1.2, so disabling it would break compatibility. Keep it enabled.

TLS 1.1 and 1.0: deprecated. These versions have known vulnerabilities and all major browsers have dropped support. Disable them.

SSLv3 and below: broken. SSLv3 is vulnerable to the POODLE attack. SSLv2 has multiple critical flaws. These should never be enabled.

The right configuration supports TLS 1.2 and 1.3 only.

In Nginx

ssl_protocols TLSv1.2 TLSv1.3;

In Apache

SSLProtocol -all +TLSv1.2 +TLSv1.3

In Caddy

Caddy enables TLS 1.2 and 1.3 by default and disables older versions. If you're using Caddy, you don't need to change anything.

Cipher suites

Cipher suites determine the encryption algorithms used during the TLS handshake. Weak ciphers can be exploited even over TLS 1.2.

A good TLS 1.2 cipher configuration prioritises ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key exchange and AES-GCM for encryption:

# Nginx
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

For TLS 1.3, the cipher suites are fixed by the protocol and don't need manual configuration. TLS 1.3 only uses strong ciphers by design.

Avoid: RC4 (broken), 3DES (slow and weak), CBC mode ciphers in TLS 1.0/1.1 (vulnerable to BEAST and Lucky13), and anything without forward secrecy.

Forward secrecy means that even if your server's private key is compromised in the future, past communications can't be decrypted. ECDHE provides this. RSA key exchange does not. Always prefer ECDHE.

Certificate configuration

Key length

Use at least a 2048-bit RSA key or a 256-bit ECDSA key. ECDSA keys are smaller and faster than RSA at equivalent security levels. If you're getting a new certificate, choose ECDSA unless you have a specific compatibility requirement for RSA.

Certificate chain

Your server should send the full certificate chain: your certificate plus all intermediate certificates. Missing intermediates cause trust errors on some clients even when the certificate itself is valid.

Test your chain with:

openssl s_client -connect yourdomain.com:443 -showcerts

You should see your certificate and at least one intermediate. If you only see one certificate, you're missing the chain.

Auto-renewal

If you're using Let's Encrypt (directly or through Cloudflare, Vercel, or Caddy), certificates are automatically renewed every 90 days. Make sure the renewal process is working. A surprising number of outages are caused by expired certificates on sites that should have auto-renewal.

Set a monitoring alert that checks your certificate expiry date. Tools like UptimeRobot can do this for free.

HSTS: forcing HTTPS

The Strict-Transport-Security header tells browsers to always use HTTPS for your domain. Without it, a user's first visit might happen over HTTP before your server redirects them.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000 means 1 year. The browser will remember to use HTTPS for that duration.

includeSubDomains applies to all subdomains. Make sure they all support HTTPS before adding this.

preload lets you submit your domain to the HSTS preload list, which is hardcoded into browsers. This means even the very first visit from a brand-new browser will use HTTPS.

Warning: once you enable HSTS with a long max-age, you're committing to HTTPS. If you later need to serve HTTP (you shouldn't), users will be locked out for the duration of max-age. Make sure your HTTPS setup is solid before enabling HSTS.

Submitting to the preload list

Visit hstspreload.org, enter your domain, and submit it. Your domain needs to meet several requirements: valid certificate, redirect HTTP to HTTPS, serve the HSTS header on the root domain, include includeSubDomains and preload directives, and max-age of at least 1 year.

OCSP stapling

When a browser connects to your site, it needs to check whether your certificate has been revoked. By default, it contacts the Certificate Authority's OCSP server to check. This adds latency and introduces a privacy concern (the CA sees which sites the user visits).

OCSP stapling moves this check to your server. Your server periodically fetches the OCSP response and sends it along with the certificate during the TLS handshake. Faster for the user, more private, and no dependency on the CA's availability.

# Nginx
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8;

Caddy enables OCSP stapling by default. Most managed hosting platforms (Vercel, Cloudflare, Netlify) handle this automatically.

Common mistakes

Redirecting HTTP to HTTPS without HSTS. The redirect only works after the browser makes the HTTP request. HSTS prevents the HTTP request from happening in the first place.

Mixed content. Your page loads over HTTPS but references images, scripts, or stylesheets over HTTP. Modern browsers block mixed active content (scripts) and warn about mixed passive content (images). Check your browser console for mixed content warnings.

Wildcard certificates on sensitive subdomains. A wildcard certificate (*.yourdomain.com) covers all subdomains. If a subdomain is compromised, the attacker has a valid certificate for your domain. Consider separate certificates for sensitive subdomains.

Not testing after configuration changes. After changing your TLS configuration, test it. A misconfigured cipher suite or missing certificate chain can break your site for specific browsers or clients.

How to check yours

Run your domain through Hexora at hexora.uk. It checks certificate validity, protocol versions, HSTS configuration, and flags specific issues with remediation guidance.

For a deeper analysis, use SSL Labs' server test (ssllabs.com/ssltest) which provides a detailed grade and breakdown of your TLS configuration.

Get TLS right once

TLS configuration is a set-it-and-verify-it task. Get the protocol versions right (1.2 and 1.3 only), use strong ciphers with forward secrecy, enable HSTS, and set up auto-renewal. Test it once, monitor the certificate expiry, and you're done. Your users' connections are encrypted properly, and you won't need to touch it again until something changes.