sysadmintools

SSL/TLS Certificate Checker

Look up the leaf certificate served by any host on any TCP port. See the subject, issuer, validity window, Subject Alternative Names, signature algorithm, public key, the full chain of intermediates, and the SHA-256 fingerprint.

Reading a TLS chain

The check runs openssl s_client against the hostname you supply, port 443 by default, then parses the leaf certificate, the chain the server actually transmitted, and the SAN list. Reachability and chain validity are reported in separate fields. A host can complete the handshake and still return chainValid false, because the server sent an incomplete chain.

The usual cause is a missing intermediate. Many servers send only the leaf, and the browser fills the gap from a cached intermediate or fetches it via the certificate's AIA URL. That keeps Chrome and Firefox happy while curl, Java, Python requests, and any client with a cold cache fail outright. "It loads in my browser" is not evidence that the chain is correct. Test with a client that has no cached trust path, or inspect the chain the server transmits.

Expiry draws the most attention and matters least. A certificate valid for six months that does not cover the hostname you requested is broken now. Compare the SAN entries against every name the service answers on, then check key usage, extended key usage, and the signature algorithm. SHA-1 signatures and undersized RSA keys are still deployed. SNI means a single IP can present different certificates per hostname, so probing the wrong name returns a valid certificate for the wrong service.

After a rewrite, a certificate renewal, or a load balancer swap, verify from the client's network rather than from the server. curl -v --resolve host:443:1.2.3.4 https://host/ pins the name to a chosen IP and shows exactly which chain arrives. If chainValid is false while the service appears to work, repair it before a client without browser cache heuristics, such as a payment gateway or an IoT fleet, hits it.

Related reading