SSL/TLS certificate checker.
Check a site's SSL/TLS certificate, expiry date, certificate chain, SANs and issuer, plus which TLS versions the server accepts and the cipher it negotiates. This tool actually connects to the host, so what you see is what a client gets.
Connected to 192.178.223.109:465 as smtp.gmail.com · connect 12.3ms · handshake 15.3ms JSON · text
- No OCSP response stapled
- Server still accepts TLS 1.0 or 1.1
Connection
Protocol support one handshake per version
Certificate chain 3 presented
-
leaf
smtp.gmail.com
59d left -
intermediate
WE2 (Google Trust Services)
842d left -
intermediate
GTS Root R4 (Google Trust Services LLC)
453d left
About this tool
This server opens a TCP connection to the host and port you give it, performs a TLS handshake using the SNI name (the host by default), and reports what the server sent back. The chain is then verified against the Mozilla root store (embedded in the binary, so the result does not depend on the server's operating system) and the hostname is checked against the leaf's subject alternative names. Four extra short handshakes probe whether the server accepts TLS 1.0 through 1.3 individually. It is a live connection, not a certificate transparency search, so it shows exactly what a client sees today.
What the SSL checker reports
| Check | Why it matters |
|---|---|
| Expiry date | Days left on the leaf certificate and on every intermediate. Under 14 days is flagged. An expired intermediate takes every site behind it down at once. |
| Certificate chain | Every certificate the server sent, labelled leaf, intermediate or extra, and whether the chain builds to a trusted root. A missing intermediate is the usual cause of "works in Chrome, fails in curl"; the certificate chain checker turns that into a per-client verdict. See certificate chains explained. |
| Hostname match | Whether the name you asked for appears in the SANs. A mismatch means the wrong certificate is being served, often a default virtual host. |
| SANs | Every name the certificate covers, including wildcards. Handy for spotting a forgotten www. |
| Issuer and key | Who signed it, the key type and size (RSA 2048, ECDSA P-256 and so on) and the signature algorithm. SHA-1 signatures and RSA under 2048 bits are rejected by modern clients. |
| TLS versions | Which of TLS 1.0, 1.1, 1.2 and 1.3 the server still accepts. 1.0 and 1.1 are deprecated and fail PCI DSS. |
| Cipher and ALPN | The cipher suite negotiated with a modern client and whether h2 (HTTP/2) or h3 is offered via ALPN. |
| OCSP stapling and CT | Whether a fresh revocation response is stapled to the handshake, and how many certificate transparency SCTs are embedded. |
Common SSL certificate problems
- Certificate expired: renewals that ran but never deployed are the most common cause. Check every edge or load balancer separately by putting its IP in the host field and the site name in SNI.
- Incomplete chain: the server sends only the leaf. Browsers often recover the intermediate from cache or via AIA fetching; curl, Java, Python and embedded devices do not. The certificate chain checker shows exactly which clients will refuse it and builds the corrected fullchain.
- Hostname mismatch: the certificate is for a different name. Usually the server's default certificate, because SNI routing or the virtual host is misconfigured.
- Self-signed or unknown issuer: fine internally, untrusted publicly. Private CAs show here as an untrusted chain.
- TLS 1.0 or 1.1 enabled: switch them off unless you have a documented client that needs them.
- Wrong certificate on port 25, 465 or 993: mail servers have certificates too and are checked far less often. Set the port and check.
Check when an SSL certificate expires
The Expires tile is the leaf certificate's days left; the chain list below it shows the same for every intermediate, which matters because an intermediate expiring takes down every site signed under it at once, and monitoring that only watches the leaf will not see it coming. Anything under 14 days is flagged. If you run more than one edge or load balancer, check each one separately by putting its IP address in Host and the site name in SNI: the most common expiry outage is a renewal that ran fine and was deployed to all but one of them. For a domain-wide view, the domain health checker includes the same expiry check alongside DNS, HTTP and email.
Check which TLS versions a server supports
The Protocol support grid is four extra handshakes, each offering exactly one version, so "yes" under TLS 1.0 means the server really completed a TLS 1.0 handshake, not that it advertised something. Old load balancers and appliances are the usual reason 1.0 and 1.1 are still on years after the application servers behind them were fixed. Both are deprecated (RFC 8996), fail PCI DSS, and modern browsers refuse them, so there is rarely a reason to keep them. A server that offers 1.2 but not 1.3 is missing the faster handshake and forward-secret-only cipher suites; see TLS 1.2 vs TLS 1.3 for what changes when you turn it on.
Testing with a different SNI
Setting a different SNI is handy for testing a new certificate on a shared IP before DNS is moved, or for checking the default certificate a server presents when no name matches. Put the load balancer's address in Host and the site name in SNI.
Examples
- example.com: a normal HTTPS site
- expired.badssl.com: what an expired certificate looks like
- incomplete-chain.badssl.com: a missing intermediate
- wrong.host.badssl.com: a hostname mismatch
- smtp.gmail.com:465: a mail server certificate
From the command line
curl "kirkdiamond.com/tools/tls?host=example.com" gives a plain-text report; add &format=json for structured output, &port= and &sni= as needed. Only public hosts can be inspected, and nothing about the connection is stored.
Every parameter, the JSON field names, rate limits and ready-made CI checks are in the API and curl reference.