Search tools and pages.
Probe a host:port and render the full TLS certificate chain with subject, issuer, SAN, key, signature, fingerprints, and days-until-expiry
sidebar • 160x600
Written by Giorgos Kostas. Last reviewed:
SSL Chain Inspector connects to any public `host:port` (default 443) over TLS and reads the full certificate chain the server presents. Each certificate is rendered as a card with subject, issuer, SAN list, public-key algorithm and size, signature algorithm, validity window, days-until-expiry, SHA-256 fingerprint, and OCSP stapling status.
The result is a fast, focused tool for the most common TLS questions: does my chain include the right intermediates? When does my certificate expire? Does the SAN cover the hostname I'm serving?
example.com:443
Leaf CN=example.com expires in 72 days SAN: example.com, www.example.com Key: ECDSA P-256, Sig: ECDSA-SHA384, OCSP stapled ✓ Intermediate CN=R3 issuer: ISRG Root X1 Root CN=ISRG Root X1 self-signed
The server didn't bundle intermediates; mobile clients and older browsers will throw a TLS error.
Fix: Re-deploy with the full chain (cert + intermediate(s)) in the same PEM bundle. The inspector shows what the server actually sent.
The SAN list doesn't include the hostname you connected to.
Fix: Reissue with the missing hostname in the SAN list. Wildcard SANs only match a single label depth.
Intermediate root expirations are easy to miss; clients will reject the chain even if your leaf is valid.
Fix: Pin to the long-lived intermediate published by your CA (Let's Encrypt rotates intermediates regularly).
No. SSL Labs is the gold standard for full grading (cipher suites, protocol downgrade, BEAST, weak DH params). The Chain Inspector is intentionally focused on the chain, expiry, key, and SAN — the questions that come up daily for ops and infra teams.
No. The proxy runs in the cloud and only resolves public DNS. For internal hosts, run `openssl s_client -connect host:port -showcerts` from the network where the host is reachable.
Yes — SNI is sent based on the hostname you provide. If you use a non-standard port, just append it (`example.com:8443`) and the inspector will still send SNI for `example.com`.
We log timing, the host, and HTTP status for rate-limit purposes. Certificate contents are not stored — they're parsed in-memory and returned to your browser.
When OCSP stapling is enabled, the server attaches a recent OCSP response inside the TLS handshake — the client doesn't need to reach the CA's OCSP responder separately. It improves connection time and avoids leaking visit data to the CA.
Pair the chain inspector with other web-platform debugging tools. You can also browse the full Security & Web Hardening category for more options.
Build a Content Security Policy header from per-directive cards with chip-style sources, presets, and a live header + meta-tag preview
Send a real OPTIONS preflight and the actual request from a server proxy and inspect the per-rule CORS verdict for any origin
Paste response headers to audit HSTS, CSP, CORS, X-Powered-By disclosure, and Set-Cookie flags
Inspect status, headers, redirects, and canonical hints for a URL
Inspect favicon, apple-touch-icon, and manifest links from a live page
Parse a URL into scheme, host, port, path, query parameters, fragment, and origin — fully client-side
Passive Access-Control-Allow-Origin matcher — paste a header value plus a list of origins to confirm wildcard, scheme, and subdomain rules
Decode JWTs, verify HMAC, RSA, and EC signatures (paste secret/PEM or fetch JWKS), inspect claims, and visualize the exp/nbf/iat timeline
Probe a host:port over TLS and render the full certificate chain — subject, SAN, key, signature, fingerprints, OCSP, and days-until-expiry.
content bottom • up to 300x250