Back to Tools
TLS Scanner
Scan a host for supported SSL/TLS versions and cipher suites to evaluate protocol security and compatibility.
TLS Scan Results for
Protocol Support
Certificate Information
Security Analysis
TLS scanner methodology
The TLS scanner connects to the submitted host and port to inspect negotiated protocol behavior, certificate details, and cipher support signals. It is configuration analysis, not a full vulnerability assessment or CVE detector.
What is checked
- Protocol support indicates which SSL/TLS versions the service appears to accept on the selected port.
- Cipher and certificate output should be reviewed together because compatibility and trust failures often overlap.
- SNI is used where applicable so name-based TLS endpoints can present the expected certificate.
Deployment caveats
- CDNs, reverse proxies, load balancers, and WAFs may terminate TLS before traffic reaches the origin server.
- Different hostnames on the same IP can return different certificates and cipher policies because of SNI.
- SMTP STARTTLS, IMAPS, POP3S, and HTTPS endpoints can have different TLS behavior even on the same host.
Operational limits
- The scan does not prove exploitability and should not be treated as a full security assessment.
- CVE status, application vulnerabilities, and authenticated configuration are outside this check unless explicitly shown.
- Re-test after CDN, proxy, certificate, or server configuration changes because TLS state can change per endpoint.
Related checks
Scanners may use different OpenSSL versions, cipher lists, SNI handling, timeout values, and network paths. CDNs and load balancers can also route checks to different TLS termination points.
No. Weak protocol support is a configuration risk, not evidence of compromise. Review business compatibility requirements, client support needs, and server policy before disabling protocols.
Name-based TLS uses SNI to choose a certificate during the handshake. The same IP address can serve different certificates for different hostnames.