SSL Checker
Free SSL checker that reads the certificate chain a server sends and checks trust, the host name, expiry, and which TLS versions it accepts.
Updated
A host name, a URL, or a name with a port such as mail.example.com:993.
Options
Enter a domain name such as example.com and select Check.
What Is an SSL Checker?
The SSL checker connects to a server, reads the certificate chain it sends during the TLS handshake, and checks it the way a browser would: the chain must lead to a root in the Mozilla CA store, the host name must be one of the certificate's names, and today's date must fall inside every certificate's validity period. It also tests which of TLS 1.0, 1.1, 1.2 and 1.3 the server accepts, and shows the stapled OCSP status, embedded Certificate Transparency timestamps, and the domain's CAA records.
How to Use the SSL Checker
- Enter a domain name, or paste a URL. Pick another port for mail or DNS over TLS servers.
- Press Check. The server is contacted from Cloudflare's network, which takes a few seconds.
- Read the verdict and the findings first, then the certificate, chain and protocol details.
- Copy the chain as PEM, or copy a link that reruns the same check.
How It Works
The checker opens a TCP connection and sends a TLS ClientHello itself. In TLS 1.2 and older, the server's Certificate message travels in clear. In TLS 1.3, all handshake messages after the ServerHello are encrypted, so the checker derives the server's handshake keys from its own key share (RFC 8446, section 7.1) and decrypts the server's first flight. It stops after the Certificate message and never completes the session.
The server must send its own certificate first, and each following certificate should certify the one before it (RFC 8446). The checker builds a path from the server's certificate through the certificates it sends to a root in the Mozilla CA store, as bundled with Node.js, and verifies each signature. Every certificate on the path must be inside its validity period, which runs from notBefore through notAfter inclusive (RFC 5280). A certificate that signs others must be marked as a CA in its basic constraints, and an extended key usage extension, when present, must allow TLS server authentication.
The checker compares the host name with the certificate's subject alternative names, never with the subject common name (RFC 9525). A wildcard is valid only as the whole left-most label and matches exactly one label, so *.badssl.com covers expired.badssl.com but not wrong.host.badssl.com or badssl.com.
Four handshakes test the protocol versions: one offering TLS 1.3 and 1.2 through the supported_versions extension, and one each limited to TLS 1.2, 1.1 and 1.0. RFC 8996 deprecates TLS 1.0 and 1.1.
The checker reads a stapled OCSP response (RFC 6066) from the handshake and matches it to the certificate's serial number. It does not check the response signature. It counts the signed certificate timestamps in the certificate extension defined in RFC 6962. CAA records come from the host name or, if it has none, from the closest parent name that has them (RFC 8659).
Cloudflare Workers, which run this check, cannot open TCP connections to Cloudflare IP addresses. For a site served through Cloudflare, the checker shows the address, CAA records and HSTS header, and says that the certificate cannot be read.
Standards
Scope
What It Checks
- +Reads the certificate chain a server sends over TLS 1.3, TLS 1.2 and older versions.
- +Builds the path to a root in the Mozilla CA store and checks every signature on it.
- +Names the failure: expired, not yet valid, name mismatch, self-signed, untrusted root, or incomplete chain.
- +Matches the host name against the certificate's names, with one-label wildcards.
- +Tests whether the server accepts TLS 1.3, 1.2, 1.1 and 1.0, and flags the deprecated versions.
- +Shows the stapled OCSP status, embedded SCTs, CAA records and the HSTS header.
What It Does Not Check
- -It does not read certificates of sites served through Cloudflare's network.
- -It does not query OCSP responders or CRLs, or check the OCSP response signature.
- -It does not check STARTTLS services such as SMTP on port 587.
- -It does not apply name constraints or CA distrust dates.
- -It does not rate cipher suites or test for protocol vulnerabilities.
Defensive Use
RFC 8996 deprecates TLS 1.0 and 1.1, and RFC 8446 expects a server to send its own certificate first, followed by certificates that each certify the one before. CAA records let a domain holder name the certificate authorities allowed to issue for the domain. Checking these after every renewal or server change finds a missing intermediate certificate, an expired certificate, or an old protocol version before visitors run into them.
Frequently Asked Questions
What is an SSL Checker?→
The SSL checker connects to a server, reads the certificate chain it sends during the TLS handshake, and checks it the way a browser would: the chain must lead to a root in the Mozilla CA store, the host name must be one of the certificate's names, and today's date must fall inside every certificate's validity period. It also tests which of TLS 1.0, 1.1, 1.2 and 1.3 the server accepts, and shows the stapled OCSP status, embedded Certificate Transparency timestamps, and the domain's CAA records.
What is the SSL Checker used for?→
Confirming that a new or renewed certificate is installed with its full chain, finding out why browsers show a certificate error, and checking that a server no longer accepts TLS 1.0 or 1.1.
Is my data sent anywhere?→
The SSL Checker sends the domain name and port you enter to ImmunitySec servers, which run the check and return the result. To run it, they contact the site you enter, and Cloudflare's public DNS resolver to look up its address and CAA records. Nothing else you enter leaves the page.
How is the SSL Checker used defensively?→
RFC 8996 deprecates TLS 1.0 and 1.1, and RFC 8446 expects a server to send its own certificate first, followed by certificates that each certify the one before. CAA records let a domain holder name the certificate authorities allowed to issue for the domain. Checking these after every renewal or server change finds a missing intermediate certificate, an expired certificate, or an old protocol version before visitors run into them.
What does an incomplete certificate chain mean?→
The server sends its own certificate but not the intermediate certificate that links it to a trusted root. Clients that do not already have that intermediate cannot build the chain and show an error. RFC 8446 expects the server to send its certificate first, followed by certificates that each certify the one before, so the fix is to configure the server with the full chain file from the certificate authority.
Does a wildcard certificate cover the bare domain?→
No. Under RFC 9525 a wildcard matches exactly one label, so *.example.com covers www.example.com but not example.com or a.b.example.com. A certificate that should cover the bare domain lists it as a separate name.
Why are TLS 1.0 and 1.1 flagged?→
RFC 8996, published in March 2021, formally deprecates TLS 1.0 and TLS 1.1. Servers should accept TLS 1.2 and TLS 1.3 only.
Why can the checker not read sites behind Cloudflare?→
The check runs on Cloudflare Workers, and Workers cannot open TCP connections to Cloudflare IP addresses. Sites proxied through Cloudflare resolve to those addresses, so the checker cannot reach the origin's handshake and shows a reduced result instead of a wrong one.