Your SSL Checker Isn't Telling You Which TLS Versions Are Enabled

Most SSL checkers connect to your server once, report the protocol that got negotiated, and call it done. You see TLS 1.3 and reasonably conclude your configuration is modern.

But that is the answer to a different question. A TLS handshake negotiates the highest version both sides support. A modern checker talking to your server will always land on the best available option — which tells you nothing about whether an old client could still negotiate something much worse.

The question you actually care about is: which protocol versions does my server still accept? Answering it requires opening a separate connection pinned to each version in turn.

google.com still accepts TLS 1.0

A useful demonstration, because it is easy to verify yourself:

openssl s_client -connect google.com:443 -tls1 \
  -cipher 'DEFAULT:@SECLEVEL=0' </dev/null 2>&1 | grep Protocol

    Protocol  : TLSv1

That is a completed TLS 1.0 handshake with Google, in 2026. We saw the same result against three separate Google edge IPs from Ireland, and Qualys SSL Labs — testing from the United States — grades google.com a B across all ten of its front ends, which is exactly the cap SSL Labs applies when TLS 1.0 or 1.1 remain enabled.

The -cipher 'DEFAULT:@SECLEVEL=0' flag matters, and its absence is why most people never discover this. OpenSSL 3 refuses to initiate TLS 1.0 at its default security level, so without that flag you get a handshake failure locally and conclude the server rejected you. It didn't — your own client did.

This is not a vulnerability in Google's infrastructure, and they presumably keep it for compatibility with old devices. The point is narrower: if a site as well-resourced as google.com still has TLS 1.0 enabled, the odds that your own estate is clean by assumption are not good.

Why it matters even if nothing uses TLS 1.0

The practical risk from TLS 1.0 in 2026 is low, because almost no legitimate client needs it. The compliance consequence is not.

PCI DSS has required TLS 1.0 to be disabled since version 3.2, and 4.0 tightened protocol expectations further. An assessor does not ask what your browser negotiated — they test what the server accepts. A site serving TLS 1.3 to every real user and quietly accepting TLS 1.0 is a finding.

The same applies to ISO 27001 evidence around cryptographic controls, Cyber Essentials, and most vendor security questionnaires. "We use TLS 1.3" is not the claim being assessed.

Testing it properly

To enumerate support you have to probe each version separately:

for v in tls1 tls1_1 tls1_2 tls1_3; do
  printf "%-8s " "$v"
  openssl s_client -connect example.com:443 -$v \
    -cipher 'DEFAULT:@SECLEVEL=0' </dev/null 2>&1 \
    | grep -q "Protocol  : TLS" && echo "ENABLED" || echo "not enabled"
done

Two things trip people up. The security-level flag, as above — omit it and TLS 1.0 and 1.1 will always look disabled regardless of the server. And OpenSSL builds vary: some distributions compile out TLS 1.0 entirely, in which case the probe cannot be performed at all and you need a different client.

Our SSL checker does this enumeration automatically — four separate handshakes, one per version — and reports each as enabled or not rather than reporting whichever one happened to win. It also flags the deprecated ones explicitly, because that is the finding that costs you in an assessment.

The same blind spot applies to certificate chains

There is a second measurement gap with the same shape. If your server does not send intermediate certificates, browsers usually succeed anyway — they cache intermediates encountered on other sites, and some fetch missing ones via the certificate's AIA extension.

So the site looks fine to you, while curl, Java clients, older Android devices and payment gateways fail to verify it. The failure is intermittent by client rather than universal, which makes it genuinely difficult to diagnose from a browser.

The fix is nearly always configuring your server to serve the full chain file from your CA — fullchain.pem rather than cert.pem — but you have to know to look. A checker that validates using a browser-like trust store will not tell you, because it will succeed for the same reason your browser does.

What to check on your own domains

• Whether TLS 1.0 and 1.1 are still accepted, not merely unused
• Whether the full certificate chain is served, not just the leaf
• Which hostnames the certificate actually covers
• Key type and size — 1024-bit RSA is still out there
• Whether forward secrecy is available on the negotiated suite

All of these are externally observable in under a second, and all of them are things you can be quietly wrong about for years.

Check which TLS versions your server accepts

Protocol matrix · Chain validation · Instant