TLS version and cipher suite selector, server config generator, browser compatibility matrix
Pick the right TLS versions and cipher suites for your server based on security profile, audience compatibility and compliance constraints. The tool generates a ready-to-paste nginx, Apache, Caddy or HAProxy config and shows which browsers will still connect at each setting.
How this tool decides which TLS versions to enable
The TLS version selector follows the Mozilla SSL Configuration Generator methodology adapted for 2026. The decision is driven by three axes: the security profile you target, the audience you need to keep compatible, and any compliance constraint that overrides the first two. The output is always a deterministic set of TLS versions, cipher suites and HSTS recommendations, mapped onto the exact directive your chosen web server expects.
The default Intermediate profile (TLS 1.2 + 1.3) is what every public-facing site without a specific legacy requirement should run in 2026. It blocks every known practical attack on the TLS layer, keeps every browser shipped in the last seven years working, and is endorsed by Mozilla, the IETF, NIST and PCI-DSS 4.0 as the safe baseline. The Modern profile (TLS 1.3 only) is appropriate for APIs and internal services where you control the client population. The Old profile is the explicit “I need IE11 or Android 4 support” escape hatch and the tool surfaces the trade-offs in the browser matrix so the decision is informed.
Why TLS 1.0 and 1.1 are no longer acceptable
TLS 1.0 (1999) and TLS 1.1 (2006) were formally deprecated by the IETF in March 2021 (RFC 8996). Modern browsers (Chrome 84+, Firefox 78+, Safari 14+, Edge 84+) refuse to negotiate them by default. PCI-DSS has not accepted TLS 1.0 for a card-processing endpoint since June 2018. The 2014 POODLE attack and the 2016 SWEET32 attack both demonstrated practical exploits against TLS 1.0 cipher modes. There is no scenario in 2026 where enabling TLS 1.0 on a public endpoint is the right call: even legacy compatibility is better solved by a dedicated legacy endpoint with a documented expiration date.
TLS 1.2 with modern cipher suites remains safe in 2026 because the cipher choice (AES-GCM, ChaCha20-Poly1305) and the key exchange (ECDHE) are the actual defence — TLS 1.2 itself is just the negotiation envelope. The audit failures attributed to “TLS 1.2” usually trace back to weak ciphers like 3DES, RC4, or CBC modes with HMAC-SHA1, which the tool excludes automatically when you select the Modern or Intermediate profile.
Cipher suite selection in 2026
The 2026 cipher baseline is built on three primitives. The key exchange is ECDHE with X25519 or P-256 curves. The authentication is RSA-2048 or ECDSA-P256 with a SHA-256 or SHA-384 signature. The bulk cipher is either AES-128-GCM, AES-256-GCM or ChaCha20-Poly1305. Everything else — RSA key exchange, static DH, AES-CBC modes, anything-MD5, anything-SHA1, RC4, 3DES, EXPORT ciphers — is excluded. The Modern profile reduces this further to only the AEAD ciphers (AES-GCM and ChaCha20-Poly1305) and only TLS 1.3, which automatically removes every known weakness.
ChaCha20-Poly1305 deserves a specific note: it is the right choice for mobile-heavy traffic because ARM CPUs without AES hardware acceleration (older Android, IoT devices) compute it 2-3 times faster than AES-GCM. Browsers prefer it automatically when the client signals no AES hardware. Listing it before AES-GCM in your cipher order is the small detail that improves mobile performance without harming desktop.
Compliance constraints that change the output
Compliance frameworks add specific requirements that the tool applies when you select them. PCI-DSS 4.0 mandates TLS 1.2 minimum (TLS 1.3 preferred), forbids any cipher under 112 bits of effective security, and requires a documented exception process for any TLS 1.0/1.1 endpoint still in use during the migration window. HIPAA via NIST SP 800-52 Rev. 2 requires TLS 1.2 minimum, server-side cipher preference, and a documented inventory of TLS-enabled services. FIPS 140-3 restricts the cipher suite list to FIPS-approved algorithms (no ChaCha20-Poly1305, AES-GCM only with specific implementations) and requires a validated cryptographic module — your operating system’s TLS library must be on the FIPS list. NIST SP 800-52 Rev. 2 is the public-sector baseline and overlaps heavily with the Intermediate profile, with the addition of strict OCSP stapling and HSTS preload requirements.
How to deploy the generated config safely
Generating the config is the first step. Deploying it without breaking traffic is the second. The recommended sequence is: stage the config on a non-production endpoint, run the Qualys SSL Labs test, confirm the grade matches your target (A+ for Modern, A for Intermediate), and only then ship to production. On the production endpoint, enable HSTS with a short max-age first (600 seconds), confirm no clients are broken for 24 hours, then ramp to a year. Submit to the HSTS preload list only after a month of stable operation, because removal from the preload list takes weeks. Set up an expiration monitor on the certificate with a 30-day pre-expiry alert; the most common TLS outage in 2026 is still a forgotten cert renewal.
Frequently asked questions
Can I run TLS 1.3 only and break nothing?
For public web traffic, you will lose Chrome under 70, Firefox under 63, Safari under 14, Android browsers before version 10, every IE version, every Java client before 11.0.3, and most IoT devices shipped before 2019. If your analytics show none of those segments, TLS 1.3-only is the right call. Otherwise, run Intermediate (TLS 1.2 + 1.3) which covers the same modern clients plus the long tail.
Should I prefer server cipher order or client cipher order?
Server-side ordering for TLS 1.2 (directive: ssl_prefer_server_ciphers on on nginx). For TLS 1.3, the cipher list is much smaller and there is no security difference between server and client preference; the browsers and servers tend to converge on the same first choice anyway.
Do I need OCSP stapling?
Yes. OCSP stapling lets the server provide the certificate revocation status, removing one round trip to the CA per new connection. Enable it (ssl_stapling on on nginx) and configure a resolver. Without stapling, modern browsers either silently skip revocation checking or block the connection on slow CA responses.
What about ECDSA certificates versus RSA?
ECDSA-P256 is faster, smaller (about 80 bytes vs 320 bytes for the public key) and the right default in 2026. Some legacy clients still require RSA-2048, so most production setups serve both via dual-certificate configuration; the tool generates the appropriate directives when you pick the Intermediate profile.
Is Caddy really safer out of the box?
Caddy ships with the Modern profile equivalent by default, refuses TLS 1.0/1.1, and handles certificate renewal automatically via ACME. The drawback is less granular control: for compliance audits that require explicit cipher inventories, nginx or Apache is easier to document. Caddy 2.x in production is a defensible default for new projects.
How often should I regenerate this config?
Annually at minimum, after any TLS-related CVE disclosure (TLS-related CVEs averaged 4 per year over 2020-2025), and whenever you switch web servers. The cipher landscape is stable in 2026 but post-quantum migration begins in 2027-2028 with Kyber and Dilithium, so plan a TLS layer refresh in that timeframe.
