If you've just added your site to Cloudflare, you might assume your TLS configuration is solid. You'd be wrong.
By default, Cloudflare sets your minimum TLS version to 1.0 — a protocol from 1999 that has known vulnerabilities and has been deprecated by every major browser. HSTS is off. Your SSL Labs score is likely sitting at a B or lower, and you don't even know it.
I learned this the hard way while hardening my self-hosted site. Here's every setting I changed to go from Cloudflare's defaults to an A+ on SSL Labs — and why each one matters.
The Problem With Cloudflare's Defaults
Cloudflare is an excellent CDN and security layer, but it optimizes for maximum compatibility out of the box, not maximum security. That means:
- Minimum TLS Version: TLS 1.0 (vulnerable, formally deprecated by the IETF in 2021)
- HSTS: Disabled
- TLS 1.3: Enabled, but undermined by allowing TLS 1.0/1.1
This is a reasonable default for Cloudflare. They serve millions of sites, some of which still need to support ancient clients. But for your modern web application, there's no reason to keep these settings.
Step 1: Raise the Minimum TLS Version
This is the single most impactful change. Go to SSL/TLS → Edge Certificates and find "Minimum TLS Version."
You'll see a dropdown defaulting to TLS 1.0. Change it to TLS 1.2.
Why TLS 1.2 and not 1.3? Because TLS 1.2 is the floor — clients that support TLS 1.3 will still negotiate 1.3 automatically. Setting the minimum to 1.2 just cuts off the insecure protocols (1.0 and 1.1) that no modern browser needs anyway. Every major browser dropped TLS 1.0/1.1 support in 2020.
While you're here, make sure TLS 1.3 is toggled on. It should be by default, but verify it.
Step 2: Enable HSTS
HTTP Strict Transport Security tells browsers to always use HTTPS for your domain — no exceptions, no fallback to HTTP. Without it, a first-time visitor could be intercepted before the HTTPS redirect kicks in.
Go to SSL/TLS → Edge Certificates and click "Change HSTS Settings." Enable everything:
- Enable HSTS: On
- Max-Age: 12 months (the maximum — shorter values weaken the protection)
- Include Subdomains: On (if all your subdomains support HTTPS)
- Preload: On
- No-Sniff Header: On
⚠️ A word of caution: HSTS is a commitment. Once a browser receives the HSTS header, it will refuse to connect over HTTP for the duration of the max-age. If you later need to serve your site over plain HTTP (you shouldn't), you'll have a bad time. Make sure HTTPS works perfectly before enabling this.
The "Preload" option adds the preload directive to your HSTS header, which signals that your domain is eligible for the HSTS Preload List built into browsers. Once on the list, even the very first visit will be forced to HTTPS. But enabling the toggle alone isn't enough — you still need to manually submit your domain at hstspreload.org after configuring these settings. Inclusion can take weeks or months to propagate through browser releases, and it's the hardest setting to undo.
Step 3: Force HTTPS Everywhere
Two more toggles in the same section:
Always Use HTTPS: On. This redirects all HTTP requests to HTTPS across your entire domain. Simple but essential.
Automatic HTTPS Rewrites: On. This fixes mixed content issues by rewriting http:// resource URLs to https:// on the fly. It won't fix everything (inline scripts, for example), but it catches most third-party embeds and legacy URLs.
Step 4: Enable Certificate Transparency Monitoring
This one isn't about your SSL Labs score, but it's worth enabling while you're in the settings. Certificate Transparency Monitoring sends you an email whenever a Certificate Authority issues a certificate for your domain.
Why does this matter? If someone manages to get a fraudulent certificate for your domain (through a compromised CA or a social engineering attack), you'll know about it immediately. It's free, it's a toggle, and there's no reason not to turn it on.
Don't forget to actually add your email address to the notification field — the toggle alone doesn't do anything without a recipient.
Step 5: Harden Your Origin Server
Cloudflare handles the connection between the visitor and Cloudflare's edge, but there's a second TLS connection between Cloudflare and your origin server. If your SSL/TLS encryption mode isn't set to Full (Strict), this connection might not be properly validated.
Go to SSL/TLS → Overview and set the mode to Full (Strict). This requires a valid certificate on your origin — either from a public CA (Let's Encrypt via Certbot works perfectly) or a Cloudflare Origin Certificate.
If you're running Nginx, make sure your origin config only allows modern protocols too:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
This mirrors what Cloudflare negotiates on the edge and ensures there's no weak link in the chain.
The Result
After making these changes, run your domain through SSL Labs and you should see an A+ rating.
The full checklist:
- ✅ Minimum TLS version → TLS 1.2
- ✅ TLS 1.3 → On
- ✅ HSTS → On (Max-Age 12 months, includeSubDomains, Preload)
- ✅ Always Use HTTPS → On
- ✅ Automatic HTTPS Rewrites → On
- ✅ Certificate Transparency Monitoring → On
- ✅ SSL/TLS mode → Full (Strict)
- ✅ Origin server → TLSv1.2 + TLSv1.3 only, strong ciphers
One Thing You Can't Fix on the Free Plan
You might still see some CBC cipher suites in your SSL Labs report under TLS 1.2. These are weaker than the preferred GCM and CHACHA20 ciphers but still considered safe in practice.
On Cloudflare's free plan, you can't customize the edge cipher suite — that requires the Business or Enterprise plan. This won't prevent you from getting an A+, but it's worth knowing about if you're aiming for a theoretically perfect configuration.
Why Bother?
A fair question. Your site works fine with Cloudflare's defaults, and the average user will never notice the difference.
But TLS hardening isn't about showing off a green badge. It's about eliminating known-weak protocols that exist only for backward compatibility with clients that shouldn't be accessing your site anyway. TLS 1.0 has known vulnerabilities (BEAST), and older SSL protocols it often coexists with are vulnerable to POODLE. HSTS prevents SSL stripping attacks. These aren't theoretical risks — they're well-documented attack vectors.
It takes about five minutes to change these settings. There's no performance penalty. The only "cost" is dropping support for Internet Explorer on Windows XP — and that's a feature, not a bug.
Originally on my blog. More stuff on web dev, devops, privacy, LLMs, and self-hosting there.
Top comments (0)