SSL/TLS security best practices

Having a valid certificate isn't enough: how the server uses it matters just as much. Here are the settings that make a difference, ranked from most important to most "fine-tuning".

1. Disable old protocols

Only TLS 1.2 and TLS 1.3 should stay enabled. SSL 3.0, TLS 1.0 and TLS 1.1 are obsolete: browsers no longer use them, and leaving them open only adds risk.

Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

For cipher suites, there's no need to build your own list: Mozilla's SSL Configuration Generator produces an "Intermediate" configuration for Nginx, Apache, HAProxy and many others.

2. Serve the full chain

Your server must send the certificate and its intermediates: the fullchain.pem file with Let's Encrypt, or a "certificate then intermediates" concatenation for a commercial certificate. An incomplete chain sometimes works in desktop Chrome, but breaks mobile apps, curl and many API integrations.

3. Protect the private key

• Restricted permissions: chmod 600, readable only by root or the web service.
• Never in a Git repository, a ticket, an email or a public Docker image.
• A key of at least RSA 2048-bit, or ECDSA P-256, which is lighter and just as secure.
• If you suspect a leak: revoke the certificate and generate a new key. Simply renewing with the same key is not enough.

4. Force HTTPS and enable HSTS

Redirect all HTTP traffic to HTTPS with a 301 redirect. Then add the HSTS header: it tells the browser never to attempt an unencrypted connection to your domain again.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Be careful: with HSTS enabled, an expired certificate becomes blocking. Visitors can no longer bypass the warning, even if they want to. Start with a short max-age (one week), check that all your subdomains are on HTTPS, then increase the value. Only add includeSubDomains if all your subdomains have a valid certificate.

5. Avoid mixed content

An HTTPS page that loads images, scripts or fonts over http:// loses its padlock, and browsers block the affected scripts. Look for hard-coded URLs in your templates and database (a classic issue on WordPress after switching to HTTPS). The following header can act as a safety net:

Content-Security-Policy: upgrade-insecure-requests

6. Limit wildcard certificates

A *.example.com certificate is convenient, but its private key grants access to every subdomain. If it's copied to ten servers, compromising just one exposes all the others. Use one certificate per service when you can: with automation, it's free and effortless.

7. Restrict authorized authorities (CAA)

A DNS CAA record specifies which authorities are allowed to issue certificates for your domain. All others will refuse the request.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 iodef "mailto:security@example.com"

8. Monitor expiration dates

This is the number one cause of HTTPS incidents, far ahead of cryptographic flaws. With 200-day certificates today and 47-day certificates in 2029, renewals will happen more and more often. So will the chances of one failing silently.

• Automate renewal wherever possible.
• Monitor anyway from the outside: automation can break without warning.
• Notify several people: an alert sent to a single inbox often ends up ignored during vacations.

SSL Expiration Reminder checks your certificates every day and alerts the whole team by email, Slack, Telegram or webhook. You can try it for free with up to 3 domains.

Checklist

• TLS 1.2 and 1.3 only
• Full chain served (fullchain)
• Private key protected, RSA 2048 or ECDSA
• HTTP → HTTPS redirect and HSTS
• No mixed content
• CAA record
• Expiration monitoring with alerts sent to several people

For a quick audit of your site, run the SSL checker.