SSL/TLS Certificate Checker

A scan from the form above checks the certificate the way a client does: the chain up to a trusted root, the hostname, the validity dates and the revocation status through OCSP and CRL. The report shows each check on every address the host resolves to, with the reason when a check fails, and an invalid certificate grades F.

Trust depends on the chain the server sends. The report lists every certificate from the leaf to the root and shows whether the chain validates against trusted root certificates. A missing intermediate is named in the report, because browsers often repair the gap on their own while curl, Java and older Android devices reject the connection.

The report shows the expiry date and the days remaining for the certificate on every address. The API returns the same figure as days_until_expiry, so a cron job or CI pipeline raises an alert well before the date.

The TLS Versions card in the report shows each version from SSL 3.0 to TLS 1.3 the server accepts, based on a separate handshake per version, and marks a version as not tested when the check was unable to run. SSL 2.0 is probed separately, as part of the DROWN check. The client simulation then shows which browsers, libraries and crawlers connect, and with which version.

TLS 1.3 and TLS 1.2 are the current versions. TLS 1.2 stays secure with forward-secret AEAD cipher suites, as RFC 9325 recommends, and the report flags every weaker suite a server still offers. TLS 1.0 and 1.1 are deprecated by RFC 8996 and cap the grade at B, and the client simulation names the clients still depending on the old versions.

TLS replaced SSL. SSL 3.0 was the last SSL version, deprecated by RFC 7568 in 2015, and "SSL certificate" now means a certificate used for TLS. The scan still checks whether a server offers SSL 3.0, which caps the grade at C, and probes for DROWN, an attack through SSL 2.0.

Yes. Every check, the API and the MCP server are free, with no account, signup or API key. Rate limits per address keep the service available for everyone.

Every scan checks the full certificate chain, hostname match, expiry, key strength and permitted key usage, the certificate served without SNI, supported TLS versions, cipher suites and key-exchange groups, known vulnerabilities (Heartbleed, ROBOT, Ticketbleed, DROWN, POODLE, FREAK, Logjam and more), a client simulation across 160+ recorded browser and library handshakes, compromised-key lookup, HSTS, CAA, OCSP / CRL revocation status, and connection-security details like Extended Master Secret and post-quantum key exchange.

SSLtest supports 14 protocols. HTTPS, FTPS, SMTPS, POP3S, IMAPS and LDAPS use TLS from the first byte, and SMTP, SMTP submission, IMAP, POP3, FTP, LDAP, XMPP and NNTP negotiate TLS through STARTTLS.

The grade summarises protocol support, cipher strength, key exchange and certificate quality, following the current TLS best practice in RFC 9325 (BCP 195, which obsoletes RFC 7525). Serious findings cap the grade regardless of the rest. What a standard prohibits outright caps at F: a revoked certificate, a key below 1024 bits, a certificate invalid for TLS server authentication, RC4 (RFC 7465) or a critical vulnerability. SSLv3 (RFC 7568) and other vulnerabilities cap at C, and deprecated TLS 1.0/1.1 (RFC 8996) or static RSA key exchange (RFC 10015) cap at B.

Each report stays available as a shareable permalink for 24 hours. The Re-scan button on the report page fetches a fresh result at any time.

A padlock means one client reached one address and accepted the certificate. Browsers also repair a broken chain quietly: given a missing intermediate they fetch the missing certificate themselves, or reuse one cached from another site, and show a padlock over a server sending an incomplete chain. The grade describes the server, not one visit.

The cause is almost always a missing intermediate certificate. curl, Python requests, Node, Go and Java build the chain only from the certificates the server sends, so a gap browsers fill in on their own becomes "unable to get local issuer certificate" or "PKIX path building failed". Older Android devices fail the same way. The fix is serving the full chain, which for most tooling means fullchain.pem rather than cert.pem.

Every scan replays the ClientHello real crawlers send, recorded from live crawler traffic and refreshed whenever the crawlers change. A host offering only ciphers Googlebot no longer accepts shows up in the report as a failed client, rather than as an unexplained drop in crawling. Browsers and crawlers are listed separately, each with the TLS version and cipher negotiated.

A scan opens a number of TLS connections and reads what the server sends back. Most are ordinary handshakes, the kind a browser or mail client makes. The vulnerability checks also send deliberately malformed records, such as broken padding or a handshake message out of order, because the way a server answers those reveals known flaws. A patched server rejects them and keeps running. Nothing is written to the server and no credentials are tried. Owners preferring no scans at all publish the DNS record described on the opt-out page, and every scan of the host is refused from then on.