TLS version and cipher suite selector, server config generator, browser compatibility matrix
Pick your TLS versions and cipher suites. You tell it three things: how locked-down you want to be, which visitors you can’t afford to lock out, and whether some auditor is breathing down your neck. Out comes a config you paste straight into nginx, Apache, Caddy or HAProxy. And it tells you, honestly, which browsers stop connecting at each setting. That last part is the bit people forget.
How this tool decides which TLS versions to enable
Under the hood it leans on Mozilla’s SSL Configuration Generator, just dragged forward to 2026. The logic runs on two knobs and a veto. The security profile you target. The audience you can’t break. Then compliance, which quietly overrides whatever you picked if a rule says so. Whatever you feed it, the output is the same shape every time: a fixed set of TLS versions, cipher suites and an HSTS line, dropped into the exact directive your server actually wants. No guessing at syntax.
Honestly, if you’re not sure what to pick, pick Intermediate (TLS 1.2 + 1.3) and move on. It’s the right answer for basically every public site in 2026 that doesn’t have some weird legacy gun to its head. Every practical attack on the TLS layer? Blocked. Every browser from roughly the last seven years? Still works. Mozilla, the IETF, NIST and PCI-DSS 4.0 all point at it as the sane floor. Modern (TLS 1.3 only) is for APIs and internal stuff where you own every client. And Old is the “fine, I genuinely need IE11 or Android 4” escape hatch, with the matrix spelling out exactly what you’re trading away so you’re not flying blind.
Why TLS 1.0 and 1.1 are no longer acceptable
They’re old. TLS 1.0 dates to 1999, TLS 1.1 to 2006, and the IETF formally put them down in March 2021 (RFC 8996). Today’s browsers won’t even negotiate them: Chrome 84+, Firefox 78+, Safari 14+, Edge 84+, all refuse by default. PCI-DSS stopped accepting TLS 1.0 on a card-processing endpoint back in June 2018. POODLE in 2014, SWEET32 in 2016, both were real working attacks on TLS 1.0 cipher modes, not theory. So in 2026 there’s just no version of “turn TLS 1.0 back on for a public endpoint” that ends well. Even the legacy case is better served by a separate legacy endpoint with a kill date written down somewhere.
TLS 1.2 is a different story, and I think this trips people up. It’s still fine in 2026, because the version number was never the thing protecting you. Your cipher (AES-GCM, ChaCha20-Poly1305) and your key exchange (ECDHE) do the defending. TLS 1.2 is just the envelope they ride in. When a scanner flags “TLS 1.2” as the problem, dig in and it’s almost always the company it’s keeping: 3DES, RC4, CBC modes bolted to HMAC-SHA1. Pick Modern or Intermediate here and those get dropped for you, no manual cipher-string surgery required.
Cipher suite selection in 2026
The 2026 baseline really comes down to a handful of moving parts. Key exchange is ECDHE on X25519 or P-256. Authentication is RSA-2048 or ECDSA-P256, signed with SHA-256 or SHA-384. And the bulk cipher is one of AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305. Everything that isn’t on that short list gets thrown out: RSA key exchange, static DH, the AES-CBC modes, anything touching MD5 or SHA1, RC4, 3DES, the ancient EXPORT junk. Modern trims even harder, down to just the AEAD ciphers (AES-GCM and ChaCha20-Poly1305) on TLS 1.3 alone, which is a blunt way to make every known weakness simply not be an option.
One word on ChaCha20-Poly1305, because it’s underrated. On phones it’s a quiet win. ARM chips without AES hardware (think older Android, a lot of IoT) chew through it maybe 2 to 3 times faster than AES-GCM. Browsers already know this and ask for it when the client says it has no AES acceleration. So put it ahead of AES-GCM in your order. Tiny edit, real mobile speedup, and your desktop users never notice the difference.
Compliance constraints that change the output
Pick a framework and the tool quietly bends the output to match its rules. PCI-DSS 4.0 wants TLS 1.2 as the floor (1.3 if you can), bans any cipher below 112 bits of real strength, and insists you write down an exception process for whatever TLS 1.0/1.1 endpoint is still limping along mid-migration. HIPAA which mostly defers to NIST SP 800-52 Rev. 2, asks for TLS 1.2 minimum, server-side cipher preference, plus an actual inventory of which services even speak TLS. FIPS 140-3 is the fussy one: only FIPS-approved algorithms, so ChaCha20-Poly1305 is out and AES-GCM only counts with the right implementation behind it. And it needs a validated crypto module, meaning your OS TLS library has to be on the FIPS list, full stop. NIST SP 800-52 Rev. 2 is the public-sector baseline. It mostly mirrors Intermediate, then layers on stricter OCSP stapling and HSTS preload demands.
How to deploy the generated config safely
Generating the config is easy. Shipping it without nuking live traffic is where people get burned. So go slow. Stage it somewhere that isn’t production, run the Qualys SSL Labs test, and check the grade landed where you wanted (A+ for Modern, A for Intermediate). Only then push it out. The HSTS part deserves real caution: start with a tiny max-age, say 600 seconds, sit with it for a full day, watch for anything broken, and only then crank it up toward a year. Don’t rush the preload list either. Wait a month of boring, uneventful uptime first, because pulling yourself back off that list later takes weeks and it’s miserable. Oh, and put a 30-day pre-expiry alarm on your cert. I’ll be blunt, the number one TLS outage in 2026 is still some poor soul forgetting to renew a certificate. It’s almost funny. It’s not funny when it’s you.
Frequently asked questions
Can I run TLS 1.3 only and break nothing?
Depends who’s knocking. On public traffic you’d drop Chrome under 70, Firefox under 63, Safari under 14, any Android browser older than version 10, the whole IE family, Java clients before 11.0.3, and most pre-2019 IoT gear. So go look at your analytics. If literally none of those show up, sure, TLS 1.3-only is the clean move. If they do, run Intermediate (TLS 1.2 + 1.3) instead. Same modern clients, but it catches the long tail you’d otherwise quietly lock out.
Should I prefer server cipher order or client cipher order?
For TLS 1.2, go server-side. That’s ssl_prefer_server_ciphers on on nginx. For TLS 1.3 it barely matters. The cipher list is short, server preference and client preference give you the same security either way, and in practice both ends usually land on the same first pick anyway. So I wouldn’t lose sleep over the 1.3 case.
Do I need OCSP stapling?
Yeah, turn it on. Stapling lets your server hand over the cert’s revocation status itself, which saves a round trip to the CA on every fresh connection. Flip it on (ssl_stapling on on nginx) and point it at a resolver. Skip it and browsers do one of two unappealing things: shrug and stop checking revocation at all, or hang the connection while a sluggish CA takes its time.
What about ECDSA certificates versus RSA?
Go ECDSA-P256. It’s quicker, and the public key is tiny next to RSA, roughly 80 bytes against 320. In 2026 it’s just the sensible default. Snag is, a few stubborn legacy clients still insist on RSA-2048, so plenty of production boxes simply serve both with a dual-certificate setup and call it a day. Pick Intermediate and the tool writes those directives for you.
Is Caddy really safer out of the box?
Kind of, yeah. Out of the box Caddy basically gives you the Modern profile, slams the door on TLS 1.0/1.1, and renews your certs on its own through ACME. The catch is the flip side of that convenience: you get less fine-grained control. When an audit wants an explicit, line-item cipher inventory, nginx or Apache is honestly easier to paper-trail. For a fresh project, though? Caddy 2.x in production is a perfectly defensible call.
How often should I regenerate this config?
Once a year, bare minimum. Also any time a TLS-related CVE drops (those landed around 4 a year across 2020 to 2025), and any time you swap web servers. Things are calm in 2026, but don’t get comfy. Post-quantum migration kicks off around 2027 to 2028 with Kyber and Dilithium, so pencil in a proper TLS-layer refresh for that window and you won’t get caught flat-footed.
