SSL/TLS checker
Scan a server’s TLS setup from Cloudflare’s network: protocol versions, every accepted cipher suite, key-exchange groups including post-quantum X25519MLKEM768, and the certificate chain, graded with the reasons.
By using these tools you accept the Terms and the Privacy page.
How the TLS checker scans a server
The TLS checker connects to a server the way a client would and records what it accepts, from protocol versions to the certificate chain. It is for anyone who runs a website, mail server or other TLS service and wants to find weak settings before clients start refusing to connect.
How the scan works
To list cipher suites, the checker offers a list of suites, notes the one the server picks, removes it and asks again until the server refuses. Key-exchange groups are found the same way: with an empty key share, a TLS 1.3 server has to answer with a HelloRetryRequest naming the group it wants. TLS 1.0 and 1.1 only count as enabled if the server goes on to send its certificate, since some front ends answer with a compatibility hello and then an alert.
The certificate chain is walked from the leaf to a root in the Mozilla root store, and every signature on the way is verified, so a chain that merely names a trusted root fails. Name matching follows RFC 6125: an exact name, or a wildcard in the left-most label only.
Understanding the findings
Findings come first, failures before warnings, and most problems carry a fix, many with the exact server setting to change. The protocol table separates “Not offered”, where the server refused, from “Not checked”, where a probe got no answer in time; an unknown result isn’t counted as unsupported.
Each suite is rated Strong (forward secret with authenticated encryption), Weak or Insecure. When some probes time out, the result says the lists may be incomplete and the scan isn’t cached, so checking again starts a new scan.
Common problems and fixes
- Intermediate certificate missing. Browsers may cope, but many other clients, mail servers included, fail to verify. Serve the full chain file from your CA, leaf first.
- TLS 1.0 or 1.1 enabled. Both are deprecated (RFC 8996); allow only TLS 1.2 and 1.3.
- Certificate expiring within 15 days. Renew it now and automate renewal.
- No post-quantum key exchange. X25519MLKEM768 protects recorded traffic against “record now, decrypt later”, and recent TLS libraries support it.
- No HSTS header on port 443. A first visit over plain HTTP can be downgraded. Send
Strict-Transport-Security: max-age=31536000; includeSubDomains.
Related checks
A clean TLS grade covers the connection, not what the site sends over it. Run the security headers check for HSTS, CSP and cookies. For a mail server, the DANE checker shows whether senders can pin its certificate.
Updated · Maintained by Liviu Tanase
Questions
What does the TLS checker test?
It opens real TLS handshakes to your server with its own TLS engine and records what the server accepts: TLS 1.0, 1.1, 1.2 and 1.3, every cipher suite per version, the TLS 1.3 key-exchange groups including the hybrid post-quantum X25519MLKEM768, ALPN (HTTP/2), the certificate chain with its names, validity, key and signature, OCSP stapling, Certificate Transparency proofs, and on port 443 the HSTS header.
How is the grade worked out?
It follows SSL Labs’ published caps. TLS 1.0 or 1.1, no forward secrecy, no AEAD suites, DH parameters under 2048 bits or an incomplete chain cap the grade at B. 3DES caps it at C. RC4, DES, NULL, export or anonymous suites, and any certificate browsers reject (expired, wrong name, self-signed, SHA-1, RSA under 2048 bits) give an F. A+ needs TLS 1.3, only strong suites, a clean certificate and, on HTTPS, HSTS of at least 180 days. Every cap is listed with its fix.
Which ports can I scan?
TLS service ports only: 443 and 8443 (HTTPS), 465 (SMTPS), 25 (SMTP between mail servers, with STARTTLS), 587 (SMTP submission with STARTTLS), 993 and 143 (IMAP over TLS and with STARTTLS), 995 and 110 (POP3), 636 (LDAPS), 853 (DNS over TLS), 990 (FTPS), 5061 (SIP over TLS), and 2083, 2087 and 2096 (cPanel, WHM and webmail). The checker is not a port scanner, so other ports are refused.
How do I check if an SSL certificate is valid or about to expire?
Enter the hostname and pick the port. The checker reads the certificate the server really sends and shows its names, issuer, validity dates and days left. An expired certificate, one not valid yet or one that doesn’t cover the hostname fails the grade; fewer than 15 days left is a warning. For a mail server, scan port 25, 465 or 587 the same way, and use the DANE checker to see whether its TLSA records match that certificate.
Why is my certificate “not publicly trusted” or the chain incomplete?
The chain the server sent is followed from the leaf to a root in the Mozilla root store, verifying every signature. Not trusted means it ends at a root outside that store (self-signed or a private CA), or a certificate on the way may not issue (not a CA, no keyCertSign, past its path length, no server-authentication usage) or is signed with SHA-1. Incomplete means an intermediate is missing: serve your CA’s full chain file, leaf first. Chains with name-constrained intermediates are marked “not checked”, never trusted.
Why can’t it read the certificate of some servers?
TLS 1.3 encrypts the certificate. The checker reads it from a TLS 1.2 handshake, or, on a server that only speaks TLS 1.3, by decrypting its handshake, which needs X25519 and an AES-GCM suite. A server that accepts neither is still graded on protocols, suites and groups, and the result says the certificate wasn’t graded. Sites behind Cloudflare are scanned too: Cloudflare doesn’t let Workers open raw connections to its own network, so those scans (and port 25) run from a separate scanner on Cloudflare’s container platform, with the same engine.
Is the scan visible to the server, and is anything stored?
The server sees 25 to 60 short handshakes (64 at most) from Cloudflare’s network that stop after the server’s first reply, plus, on port 443, one ordinary HTTPS request for the HSTS header. Results are cached at the edge for five minutes so repeat checks are fast, and “Check again” bypasses the cache. zerobounce.ai’s own logs don’t keep the hostname; Cloudflare’s request logs do, as the privacy page explains.