SSLBoard tests which TLS versions an endpoint supports. This describes what it can negotiate with a compatible client; it does not mean every visitor uses every listed version.
Interpret version support
| Observation | Meaning |
|---|---|
| SSLv3 or TLS 1.0 supported | The score treats this as a critical protocol issue. Investigate the server or proxy configuration. |
| TLS 1.1 supported | A deprecated version remains available; the individual scoring rule is a warning. |
| TLS 1.2 supported | Review its cipher suites and forward secrecy along with version support. |
| TLS 1.3 supported | Modern protocol support was observed, but older versions may still be enabled. |
| Missing TLS 1.3 | A modernization gap on assessed hosts, rather than proof that every connection is insecure. |
| No usable version data | Support could not be established. Check connection errors before interpreting an empty list. |
The IETF recommends against obsolete SSL/TLS versions and encourages TLS 1.3. TLS 1.2 deployments also need appropriate cryptographic settings. TLS deployment recommendations
Why addresses disagree
Different servers behind the same hostname can have different TLS configurations. One address may have been missed during a rollout, or IPv6 may reach a different proxy. The detailed per-IP view helps locate that difference.
Host-level summaries can combine observations from several addresses. Use endpoint evidence when planning a change, especially when a summary shows both modern and deprecated support.
Change and verify
Identify the TLS terminator, review legitimate client requirements, and apply the intended version policy there. Retest all affected addresses after the change. Check that deprecated versions are no longer listed and that intended clients still connect.
Continue with cipher suites and forward secrecy, since version support alone does not describe the whole configuration.