Skip to main content
TLS · SSL · cert chain

TLS certificate checker.

Inspect the cert chain, protocol, cipher, ALPN, and HSTS for any host. Plus an A–F grade. Works on any port; default is 443.

What this checker does

We open a real TLS handshake to host:port, walk the certificate chain from the leaf all the way to the root, and surface the details that actually decide whether a browser will trust the connection — issuer, validity window, signature algorithm, public-key size, Subject Alternative Names, and the SHA-256 fingerprint. Alongside the chain we report the negotiated protocol (ideally TLS 1.3), the cipher suite, the ALPN protocol, and whether the server sends an HSTS header.

Reading the certificate chain

A certificate on its own proves nothing. Trust comes from a chain: the leaf (your server's certificate) is signed by one or more intermediate certificates, which are ultimately signed by a root that already lives in the operating system or browser trust store. The verifier follows that chain link by link; if any signature doesn't line up, or a link is missing, the whole connection is rejected.

The single most common production TLS failure isn't an expired certificate — it's a missing intermediate. Desktop browsers often paper over the gap because they cache intermediates from earlier sites, so the page looks fine on your laptop and fails on a fresh phone, a curl request, or an API client. That's why this tool always shows the full chain the server actually sent, in order, so you can see whether the intermediate is being served at all.

Expiry, and why “days remaining” matters

Certificates are deliberately short-lived. Let's Encrypt issues 90-day certificates, and the CA/Browser Forum has capped the maximum lifetime of new public certificates at 398 days, with a phased move toward much shorter windows. Short lifetimes limit the damage from a leaked key, but they also mean renewal has to be automated — a forgotten cron job is how most TLS outages start. We colour the “days remaining” figure so anything inside 30 days reads as a warning and anything inside 14 days as urgent.

Common TLS errors, in plain English

  • Authority invalid / self-signed — the chain doesn't terminate at a trusted root. Either it is genuinely self-signed, or the intermediate is missing.
  • Hostname mismatch — the certificate is valid but doesn't list the hostname you visited among its Subject Alternative Names. A certificate for example.com does not automatically cover www.example.com.
  • Expired / not yet valid — you are outside the validity window. Check the client clock too; a wrong system date produces “not yet valid” errors on perfectly good certificates.
  • Weak protocol — anything below TLS 1.2 is deprecated and refused by modern clients.

How the grade is computed

  • A — TLS 1.3 with a modern AEAD cipher (AES-GCM or ChaCha20-Poly1305).
  • B — TLS 1.2 with an AEAD cipher.
  • C — TLS 1.2 with an older CBC cipher; functional, but CBC has a long history of padding-oracle problems and is worth retiring.
  • F — Anything older than TLS 1.2.

This is a fast, friendly preview rather than a full audit. We don't probe for OCSP stapling, downgrade resistance, or specific historical vulnerabilities such as BEAST, LUCKY13, or Heartbleed. When you need that depth, run the host through Qualys SSL Labs as well.

Frequently asked questions

Does checking a certificate here expose anything?

No. The handshake happens server-side, from IPFerret to the host you entered, exactly the way any visitor's browser would connect. We don't store the result or log the hostname.

Can I check a non-standard port?

Yes — append it, e.g. mail.example.com:465 or example.com:8443. The default is 443.

Why does my site pass here but fail in an app?

Almost always a missing intermediate. Browsers hide it; stricter clients don't. Fix it by configuring your server to send the full chain (leaf plus intermediates), not just the leaf.

JSON API

Everything above is machine-readable: GET /api/tls/<host>. It's CORS-enabled and edge-cached for five minutes. Example: /api/tls/ipferret.com.

Related tools

Pair this with the DNS lookup to confirm the host resolves where you expect, the request header inspector to see security headers in context, and the explainer on how TLS and HTTPS actually work for the background.