SSLBoard tests which TLS versions each endpoint will actually negotiate. That is a list of what is reachable, not a list of what your visitors use. An attacker gets to choose from the same list, which is the whole point of the check.
What each observation means
| Observation | Meaning |
|---|---|
| SSLv3 or TLS 1.0 supported | Scored as a critical protocol issue. Go look at the server or proxy configuration |
| TLS 1.1 supported | Deprecated and still reachable. Scored as a warning |
| TLS 1.2 supported | Fine on its own. Judge it by its cipher suites and forward secrecy |
| TLS 1.3 supported | Modern support observed. Says nothing about what else is still enabled |
| Missing TLS 1.3 | A modernization gap, not proof that connections are insecure |
| No usable version data | Nothing was established. Read the connection errors before reading the empty list as good news |
The IETF’s TLS deployment recommendations argue against the obsolete versions and for TLS 1.3, and note that TLS 1.2 still needs the right cryptographic settings underneath it.
Why two addresses disagree
A host-level summary can show both modern and deprecated support at once, which usually means the addresses behind it are not identical.
Common causes: one node in a pool missed during a rollout, or IPv6 traffic reaching a different proxy than IPv4. The per-IP view is there to find exactly this. Plan the change from endpoint evidence, not from the host summary.
Change it and confirm
- Find the machine that terminates TLS. If a CDN is in front, that is the CDN, and your origin config is irrelevant to this finding.
- Check which clients you genuinely still need. Old payment terminals and embedded devices are the usual reason TLS 1.0 is still on.
- Remove the deprecated versions there.
- Retest every affected address, not just the one you fixed.
- Confirm the deprecated versions are gone and your intended clients still connect.
Version support is only a third of the picture. Continue with cipher suites and forward secrecy.