TLS 1.3: What It Changes and How to Check It
Updated 2026-11-03 · 6 min read
TLS 1.3 is the first protocol revision in a decade that removes features instead of adding them. That is what makes it faster and harder to misconfigure — and why a server that still only speaks TLS 1.2 cannot reach the top grade.
What changed from TLS 1.2
TLS 1.3 cuts the handshake from two round trips to one, and to zero on resumption. It removes static RSA and Diffie-Hellman key exchange, so forward secrecy is mandatory rather than optional. It drops CBC-mode ciphers, RC4, SHA-1 and compression entirely, and it encrypts more of the handshake — including the certificate — so intermediaries learn less.
The practical consequence is that almost every legacy weakness that used to require careful configuration is now impossible. You cannot accidentally negotiate a weak cipher on TLS 1.3, because the protocol only defines AEAD ciphers with modern hashes.
Why it matters for your grade
CertH requires TLS 1.3 for an A+ regardless of everything else. A site with a perfect certificate, strong ciphers and HSTS will sit at 95 and an A without it. That single line is the most common reason a well-run site plateaus at A.
The other reason to care is the handshake itself. On a high-latency mobile connection, one saved round trip is tens to hundreds of milliseconds on every new connection — a direct, measurable effect on perceived speed.
Enabling it
On nginx, TLS 1.3 support depends on the OpenSSL version the binary was built against. OpenSSL 1.1.1 or newer is required; check with nginx -V and look for the built with OpenSSL string before editing anything.
On Apache, SSLProtocol is enough as long as httpd is linked against a modern OpenSSL. On Cloudflare, TLS 1.3 is a zone-level toggle under SSL/TLS → Edge Certificates and has been on by default for most zones since 2021.
# nginx: does this binary even support TLS 1.3?
nginx -V 2>&1 | tr ' ' '\n' | grep -i openssl
# negotiate TLS 1.3 explicitly and print the protocol
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"
The caveats nobody mentions
Zero-RTT resumption is fast but replayable: an attacker who captures the first flight can replay it. Never allow 0-RTT on endpoints that change state on the first request, such as anything that performs a write.
Some corporate middleboxes still break on TLS 1.3. Keeping TLS 1.2 enabled alongside it is the standard compromise — you keep compatibility and still get the A+ requirement, because the grader looks for TLS 1.3 being offered, not for TLS 1.2 being disabled.
Finally, a CDN or load balancer terminating TLS hides the origin completely. Changing the origin without changing the edge changes nothing that any external scanner can see.
FAQ
Should I disable TLS 1.2 once TLS 1.3 is on?
No. Keeping TLS 1.2 enabled preserves compatibility with older clients and middleboxes and does not cost you any points. Disabling it only removes fallback options.
Does TLS 1.3 change my certificate requirements?
It makes some legacy algorithms unusable. Certificates with RSA keys are still fine, but the chain has to use signature algorithms the protocol allows — SHA-1 signatures, for example, are not usable in TLS 1.3.