Certificate is valid
The certificate is trusted and matches the requested hostname.
Check certificate validity, issuer, expiration, TLS protocol, hostname matching and trust-chain details.
The certificate is trusted and matches the requested hostname.
Browsers can't open a raw TLS socket to another server from JavaScript, so this check runs entirely on our own server: it validates the hostname with the same SSRF protections used across our tools (private, loopback, link-local and cloud-metadata addresses are always rejected), connects on port 443, and completes a real TLS handshake. The certificate, issuer, subject alternative names, serial number, public key and trust chain are all read directly from the certificate the server presents — nothing is faked or randomly generated. HSTS is checked with a separate, independent HTTPS request.
Browser JavaScript has no API to open a raw TCP/TLS connection to an arbitrary remote server and inspect its certificate - that's a server-side operation, so our own backend does the handshake and returns the result as JSON.
No. Hostnames that resolve to localhost, private IP ranges, link-local addresses or cloud metadata endpoints (like 169.254.169.254) are rejected before any connection is attempted, to prevent this endpoint from being used to probe internal infrastructure.
It's read from the certificate's own subject fields: an Organization (O=) attribute indicates Organization Validation, and specific jurisdiction/incorporation attributes indicate Extended Validation. This is a best-effort classification, not a substitute for checking the issuing CA's disclosed practices.
.NET's TLS stack doesn't currently expose whether a server stapled an OCSP response during the handshake, so rather than guess, this is honestly reported as unavailable instead of faked.
No. Each check runs live for your request only and nothing is persisted on our server.