Comprehensive SSL/TLS security analysis and vulnerability scanning
Scanning ...
This may take a few seconds
Security Score
Total Checks
Vulnerabilities
Status
Scan Results
Check
Status
Severity
Details
Error
About Security Scanner
Our free Security Scanner performs a comprehensive TLS/SSL security audit on any domain. Check supported protocols (TLS 1.0-1.3), cipher suites, vulnerability status, HSTS headers, and certificate chain completeness. Get a detailed security report in seconds.
How to Use
1Enter the domain name to scan.
2Click "Start Scan" to begin the security audit.
3Review the detailed report covering protocols, ciphers, vulnerabilities, and headers.
•Fix any TLS 1.0/1.1 support — these are deprecated and insecure
•Enable HSTS with a long max-age (6 months minimum)
•Ensure OCSP stapling is enabled for faster handshakes
What the Scanner Grades
The scanner connects to the host and grades what it actually negotiates, using the same criteria as the SSL Labs assessment people already trust. Nothing is read from a database.
Certificate and chain
Valid now: compared against the certificate's own start and end dates in UTC.
Trusted issuer: the chain has to verify, not merely parse. A missing intermediate fails here.
Hostname match: the certificate has to actually list the host you asked about.
Key strength: RSA below 2048 bits, or ECDSA on a curve that is no longer considered strong, is penalised.
Forward secrecy: ephemeral key exchange, so the session cannot be decrypted later from a captured key.
Protocol and cipher
TLS 1.0 and 1.1 are obsolete and cost points on their own, before any cipher is considered.
SSL 2 and SSL 3 are treated as outright failures; SSL 3 is the transport for POODLE and DROWN.
Heartbleed-era renegotiation and compression are checked because they remain enabled on forgotten hosts.
Revocation and stapling
Whether the certificate carries an OCSP or CRL revocation pointer at all.
Whether the server staples a revocation response so clients do not have to ask the CA.
Certificates marked must-staple that are served without a staple are treated as a fault.
Browser-facing headers
HSTS present, with a max-age long enough to survive a browser restart.
Whether HTTP redirects to HTTPS, since HSTS cannot protect the very first request.
Certificates served on the bare domain as well as the host tested.
How the grade maps
The grade is a weighted roll-up, so one weak item can cap the result even when everything else is perfect: A means modern protocols, strong keys, forward secrecy and a complete chain with nothing significant flagged; B means broadly sound with a minor or two to fix; C means a real weakness such as a weak cipher or a legacy protocol still enabled; D or lower means something actively dangerous, like an expired certificate or a broken chain. Read the findings list rather than the letter — it names the specific directive or header to change.
A useful caveat: this is a single-point-in-time test from one network location. A CDN, WAF or geo-routing layer can present different certificates in different regions, so for a global deployment it is worth scanning from more than one vantage point.
Frequently Asked Questions
It means the configuration is strong on every axis the scanner checks: a trusted, in-date certificate with a complete chain, TLS 1.2 and 1.3 only, forward-secret cipher suites, a modern key, revocation information available and preferably stapled, and HSTS in place. It is not a certificate of correctness — a grade A says nothing about how you use TLS, only that the configuration leaves no obvious opening.
Yes, along with 1.1. Both were deprecated by RFC 8996 in 2021 and have no remaining safe cipher suites: their only workable options are weak, and the protocol itself has no modern AEAD construction. The browsers that still speak them are old enough to be a security problem in their own right. If you genuinely have legacy clients, scope the old protocols to a dedicated listener rather than leaving them on the main virtual host where everything else is served.
It is a response header, Strict-Transport-Security, that tells browsers to reach your site over HTTPS only for a stated number of seconds, which stops a visitor being silently downgraded to plain HTTP by anyone sitting between them and you. The catch is that it protects nothing on the very first request, so you still need an HTTP-to-HTTPS redirect, and a max-age long enough to survive a browser restart, or the protection quietly disappears.
Usually vantage point. SSL Labs tests from several regions and can pick the best endpoint your CDN serves, while this scan is a single connection from one location and reflects exactly what it was handed. Differences also come from scanning a different hostname, testing an internal address that terminates TLS differently from the public one, or a certificate that was renewed between the two checks. Compare the specific findings, not just the letter.
No. Almost every finding is a configuration weakness that lowers how hard the site is to attack, not evidence that it has been attacked. An expired certificate costs you visitors and search rankings; a weak cipher costs you the ability to defend traffic in the future. Treat them as a work queue ordered by severity, and fix the certificate and chain items first because those are the ones that produce visible breakage.
Keep it for now. TLS 1.3 is what you want clients on, but 1.2 with modern AEAD ciphers is still sound, and turning it off breaks anything older than roughly 2020 for no real security gain. Plan to drop it when your traffic data shows nothing older connects. The version to remove first is everything below it, because 1.0 and 1.1 have no acceptable ciphers left and are what actually drag a grade down.
Not from this tool, because it connects over the public internet and your internal name will not resolve or will refuse the connection. For a self-signed certificate you already hold, paste it into the Certificate Decoder instead: it reports the subject, issuer, validity window, SANs, key type and fingerprints offline. That tells you whether the certificate is what you think it is, even though it cannot tell you what the outside world sees.
It performs an ordinary TLS handshake, negotiates ciphers, reads the certificate and makes one plain HTTP request to inspect security headers. Those are the same requests any browser or health check makes, and none of them are intrusive or repeated. Treat the resulting IP address in your server logs as a normal visitor, and expect a burst of requests when a certificate is renewed, because that is when people run this.
