SSL Certificate Checker — Live Issuer, Expiry, SANs and Chain

What a live check tells you that a pasted certificate cannot

A certificate file says what it says wherever you read it. What it cannot tell you is whether the server is actually serving it. Most TLS incidents are not bad certificates — they are the right certificate sitting on the wrong machine, a renewal that was issued but never deployed, a load balancer where one node still holds last year's file, or an intermediate the server forgot to send so half your clients fail and your browser does not. Opening a handshake is the only way to see any of that. If you already have the file and just want to read it, the X.509 certificate decoder parses it in your browser without sending it anywhere.

The fields that usually matter

Why the chain is shown separately

A client trusts a root it already holds, so the server's job is to send everything between its own certificate and that root. Browsers paper over a missing intermediate by fetching it from the URL in the Authority Information Access extension, or by reusing one they cached earlier — which is why a site can look fine in your browser and fail in curl, on a phone, or from a server-side HTTP client. The chain table here lists exactly what the server sent, in order, so a gap is visible rather than inferred.

Name matching, SNI and virtual hosts

One address commonly serves many sites, so the client names the host it wants in the TLS handshake itself, via Server Name Indication, and the server picks a certificate from that. This tool sends the hostname you entered as the SNI name, so what comes back is the certificate that host gets — not whatever the IP answers with by default. Hostname matching is then done against the subject alternative names: the common name has not been authoritative since RFC 2818 was superseded, and a certificate whose CN matches but whose SAN list does not will be rejected by every current browser.