TLS Certificate Inspector

What it does

Give it a hostname and it opens a TLS connection from the server, reads back the certificate chain the host actually presented, and decodes every certificate in it. Or paste a PEM — one certificate or a whole concatenated chain — and it decodes that instead, without the file leaving your browser.

For each certificate you get the subject and issuer distinguished names in full, the serial, the validity window with days remaining spelled out, the public key algorithm and size, the signature algorithm, and both SHA-256 and SHA-1 fingerprints. On the leaf you also get every subject alternative name, key usage and extended key usage, basic constraints, the OCSP and CA Issuers URLs, and a count of embedded signed certificate timestamps. Hostname mode adds the negotiated protocol and cipher, whether the chain verified against the server’s trust store, and whether the name you asked for matches.

How it works

Decoding is done here rather than shelling out to OpenSSL. A certificate is a DER structure defined in RFC 5280, so the tool walks the tag-length-value tree directly: the tbsCertificate, the validity pair in UTCTime or GeneralizedTime depending on which side of 2050 the date falls, the RDN sequence for each name, the SubjectPublicKeyInfo, and the extension list. RSA key sizes come from the modulus length with the leading zero byte discarded; elliptic curve sizes come from the named-curve OID. Fingerprints are SHA-256 and SHA-1 over the whole DER encoding, computed with the browser’s own crypto implementation.

Hostname mode exists because the browser cannot do it. No API exposes the peer certificate to page JavaScript — fetch gives you a response and nothing about the handshake underneath it. So the lookup runs in a Node function that calls tls.connect with SNI set, walks the presented chain, and returns the PEM to the same parser a pasted certificate goes through. Two code paths would eventually disagree and you would have no way of knowing which one was lying. Verification is not enforced on that connection, because a certificate that fails to verify is precisely the one you opened this page to look at.

Embedded SCTs are counted from the extension defined in RFC 6962. Each is a log’s signed promise that the certificate was recorded before issuance. Chrome will not trust a public certificate without them, so zero SCTs on a leaf from a public CA is a finding; zero on an internal CA is simply how internal CAs work.

The chain you see is not the chain that gets verified

This is the part that catches people. What the tool shows in hostname mode is literally the sequence of certificates the server put on the wire, and that is not the same thing as the path a client will build.

A client constructs its own path from the leaf up to something in its trust store. If the server omits the intermediate, most browsers quietly recover by fetching it from the CA Issuers URL in the leaf’s authority information access extension, so the site looks fine in Chrome and fails in curl, in older Java, and in almost every embedded HTTP stack. The reverse also happens: a server that sends a root certificate is wasting a few kilobytes on every handshake, since the client either already trusts that root or will not be persuaded by a copy the server supplied.

Cross-signing makes it stranger still: one intermediate can be signed by several roots, and a client with a newer trust store may terminate the path earlier than the chain suggests. Read the chain here as “what this server sends”, check that each subject matches the issuer above it, and treat a one-certificate chain from a public CA as something to fix.

When to reach for it

The routine use is a renewal check: how many days are left, and did the new certificate actually get deployed, or is the old one still in memory because nobody reloaded the process. The fingerprint answers the second question definitively.

It is also the fastest way to diagnose the failures where one client works and another does not. Compare the SANs against the exact name the failing client uses, count the certificates in the chain, and check the signature algorithm — a SHA-1 signature or a missing intermediate explains most of them.

Related tools

• CT log lookup for every other certificate ever issued for this name.
• DNS lookup to check the CAA records that decide who may issue next time.
• Nginx and Caddy config generator for the server block that serves this certificate.
• HTTP header inspector for the HSTS policy that depends on it.
• Hash generator when you need to compute a fingerprint over something other than a certificate.