TLS Version and Cipher Selector
Pick TLS versions and cipher suites by security profile, audience and compliance, then copy a ready config for nginx, Apache, Caddy, HAProxy or IIS.
This TLS version and cipher selector turns three plain choices into a config you can actually paste. You set how locked-down you want to be (Modern, Intermediate or Old), which visitors you cannot afford to lock out, and any compliance rule in play (PCI-DSS 4.0, HIPAA, FIPS 140-3 or NIST SP 800-52 Rev. 2), and it returns a fixed set of TLS versions, an ordered cipher suite list and an HSTS line dropped into the exact directive your server wants. Pick nginx, Apache, Caddy, HAProxy or IIS and copy the snippet straight out. Compliance quietly overrides risky picks, so choosing FIPS strips ChaCha20-Poly1305 and choosing PCI nudges an Old profile up to Intermediate, each with a note saying why. A browser compatibility matrix spells out which clients stop connecting at every setting, so you trade away old-browser reach on purpose rather than by accident. The whole thing runs in your browser, nothing you choose is sent anywhere, and the defaults track Mozilla's SSL Configuration Generator carried forward to 2026.
100% in your browser. Nothing you type ever leaves this page.
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 cannot 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 TLS version and cipher selector decides what to enable
This TLS version and cipher selector 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 cannot 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 are not sure what to pick, pick Intermediate (TLS 1.2 + 1.3) and move on. It is the right answer for basically every public site in 2026 that does not 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 are trading away so you are not flying blind.
Why TLS 1.0 and 1.1 are no longer acceptable
They are 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 will not 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 is 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 is 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 is almost always the company it is 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 is not 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 is underrated. On phones it is 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 is not 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. Do not 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 is miserable. Oh, and put a 30-day pre-expiry alarm on your cert. I will be blunt, the number one TLS outage in 2026 is still some poor soul forgetting to renew a certificate. It is almost funny. It is not funny when it is you.
Frequently asked questions
Can I run TLS 1.3 only and break nothing?
Depends who is knocking. On public traffic you would 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 would otherwise quietly lock out.
Should I prefer server cipher order or client cipher order?
For TLS 1.2, go server-side. That is ssl_prefer_server_ciphers on for 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 would not lose sleep over the 1.3 case.
Do I need OCSP stapling?
Yeah, turn it on. Stapling lets your server hand over the cert revocation status itself, which saves a round trip to the CA on every fresh connection. Flip it on (ssl_stapling on for 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 is quicker, and the public key is tiny next to RSA, roughly 80 bytes against 320. In 2026 it is 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.
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 do not 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 will not get caught flat-footed.