TLS 1.3 not enabled
Part of the Edge TLS posture check · fix arrives as a guide
What it is
TLS 1.3 is not enabled on the zone.
Why it matters
You are leaving performance and security on the table. TLS 1.3 completes its handshake in one round trip instead of two and removes the legacy cipher suites that older versions still negotiate.
Check what your zone negotiates today
# does the edge accept a TLS 1.3 handshake?
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep 'Protocol'
# Protocol : TLSv1.3 ← enabled
# (handshake failure) ← still capped at 1.2What enabling it changes
TLS 1.3 removes a full round trip from the handshake — connections start faster, most noticeably on mobile — and drops every legacy cipher that made 1.2 configurable in unsafe ways: no RSA key exchange, no CBC modes, forward secrecy always on. There is no compatibility trade: clients that cannot speak 1.3 negotiate 1.2 exactly as before. The toggle is SSL/TLS → Edge Certificates → TLS 1.3.
The one thing not to enable with it
0-RTT (“early data”) is a separate toggle that rides on TLS 1.3 session resumption. It lets a returning client send its first request in the handshake itself — and that request can be captured and replayed by an attacker. Leave it off unless your traffic is strictly idempotent; the details are on the 0-RTT check page.
Fix it manually
Flip the toggle, re-run the openssl check, and if you pin a minimum version anywhere, review it at the same time — SSL/TLS → Edge Certificates → Minimum TLS Version should be 1.2 today, with 1.3 as the ceiling the edge now offers.
How lumioguard fixes it
The scan reads the zone’s TLS configuration — 1.3, minimum version, and 0-RTT together, since they are one decision — and the fix arrives as a guide with the exact settings and the verification commands.
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.