Guides · Understand your certificate

TLS versions and ciphers: what to enable, what to turn off, and how to test

Last reviewed by a person on October 4, 2026

Every HTTPS connection starts by agreeing on a TLS version and a cipher suite (the set of algorithms used). If your server still allows old versions or weak ciphers, you fail security scans and audits even though your certificate is perfectly valid. This guide explains what to allow, what to switch off, and how to check yours in a minute.

Which TLS versions

• TLS 1.3 (2018): enable it. Faster handshake, only modern ciphers, forward secrecy always.
• TLS 1.2 (2008): keep it. Still needed by many clients and tools, and safe when set up with modern ciphers.
• TLS 1.1 and TLS 1.0: turn them off. Formally deprecated in 2021 (RFC 8996), dropped by the major browsers back in 2020, and security standards such as PCI DSS require you to disable early TLS. Visitors on devices that old are practically nonexistent.
• SSL 2.0 and 3.0: long broken. They should not exist on any server any more.

The trade-off is compatibility: turning off 1.0 and 1.1 locks out very old systems (for example Windows XP era browsers, very old Android versions and Java 6 and 7 clients). For a public website that is almost always the right trade.

What a cipher suite is, and what to avoid

A cipher suite names how keys are exchanged, how data is encrypted and how it is authenticated, for example ECDHE-RSA-AES128-GCM-SHA256. Two things matter in practice:

• Forward secrecy (ECDHE or DHE in the name). Each connection uses a one-off key, so a stolen server key later cannot decrypt traffic someone recorded earlier. TLS 1.3 always has it; on TLS 1.2 prefer suites that start with ECDHE.
• Remove weak suites: anything with NULL (no encryption), aNULL or anonymous (no authentication), EXPORT, RC4, DES or 3DES, and MD5. Browsers will not choose them, but if a server accepts them an attacker can force one.

How to test yours

The quickest way is the TLS checker: type a domain and it shows which of TLS 1.0, 1.1, 1.2 and 1.3 the server accepts and the cipher it picks for each, warns about old versions, a TLS 1.2 cipher without forward secrecy and NULL or anonymous ciphers. From a command line:

# does it accept TLS 1.2 / 1.3 (should) and 1.0 / 1.1 (should not)?
openssl s_client -connect example.com:443 -servername example.com -tls1_2 < /dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 < /dev/null

# every cipher the server accepts (needs nmap)
nmap --script ssl-enum-ciphers -p 443 example.com

A server behind a CDN or load balancer shows its settings, not your origin's. Change the minimum version where the connection ends (see below).

How to set it

nginx (in the server block or http block):

ssl_protocols TLSv1.2 TLSv1.3;

Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

For the cipher list, do not write your own from memory. Generate a current, tested one with the Mozilla SSL Configuration Generator (pick your server and the "Intermediate" profile). Then reload the server and test again.

• Cloudflare, AWS load balancers, Azure, other CDNs: set the "minimum TLS version" in their dashboard or policy.
• Hosting panels and managed hosting: look for a TLS or "security level" setting, or ask the host. You often cannot edit the web server config yourself.
• Mail and other services: the same idea applies on other ports; a web setting does not change them.

Related

If visitors see ERR_SSL_VERSION_OR_CIPHER_MISMATCH the server probably offers nothing modern: see certificate errors explained. The certificate itself is a separate check: how to check when it expires. CertAvert watches the certificate and its chain every day and emails you when something changes.