How to read a TLS/SSL certificate check result

What’s actually in a certificate check result

A TLS/SSL certificate, as defined by RFC 5280, carries a fixed set of fields regardless of which tool reads it, and a check result is really just a human-readable summary of those fields:

• Subject — the hostname(s) the certificate is issued for, listed in its Subject Alternative Name (SAN) extension.
• Issuer — the Certificate Authority (CA) that signed the certificate.
• Validity period — a notBefore and notAfter date, outside of which the certificate is not valid regardless of anything else being correct.
• Chain — the sequence of intermediate certificates linking the server’s certificate back to a root CA that the connecting client already trusts.
• Key and signature algorithm — what cryptography protects the certificate itself, separate from the TLS protocol version used for the connection.

The fields that actually decide whether a connection is trusted

Not every field carries equal weight. Three checks, done in combination, are what actually determine whether a client accepts the connection:

1. Does the hostname being connected to appear in the certificate’s SAN list? RFC 6125 specifies that a client must match the name it’s connecting to against the certificate’s SANs, not its deprecated Common Name field. A certificate issued for example.com does not automatically cover api.example.com — that subdomain needs its own entry or a matching wildcard (*.example.com).
2. Is today’s date inside the validity window? An expired certificate fails regardless of how well everything else checks out, and the CA/Browser Forum’s Baseline Requirements cap how long a publicly trusted certificate can remain valid in the first place, specifically so that key compromises and CA trust changes propagate on a bounded schedule rather than lingering for years.
3. Does the chain resolve to a trusted root? A server needs to present not just its own certificate but every intermediate certificate between it and a root the client already trusts. A result showing “chain incomplete” or “unable to get local issuer certificate” almost always means the server is missing an intermediate in its configuration, not that the certificate itself is fraudulent.

Common results and what they actually mean

• “Self-signed certificate” — the subject and issuer are the same entity, meaning no third-party CA vouched for it. Expected and fine for internal tooling you control; a red flag on anything meant to be reached by the public, since no outside party verified the operator controls that hostname.
• “Certificate expired” — the notAfter date has passed. This is purely a date comparison and the single most common reason a previously-working site suddenly shows a browser warning.
• “Hostname mismatch” — the name you connected to isn’t in the certificate’s SAN list, per RFC 6125’s matching rules. Common after a domain migration or a wildcard certificate that doesn’t cover a newly added subdomain.
• “Weak signature algorithm” — the certificate (or one in its chain) uses a signature algorithm, like SHA-1, that current Baseline Requirements and browser policy no longer treat as acceptable, regardless of key length.

How to check your own certificate

AdminKit’s SSL/TLS check tool is built to read exactly these fields — subject, issuer, validity window, chain completeness, and protocol/cipher support — and surface which ones, if any, would cause a real client to reject the connection, not just flag anything unusual. If the hostname itself is also in question (for example, confirming which server a name currently resolves to before you check its certificate), start with AdminKit’s DNS lookup tool.

Why this matters beyond “it says valid”

A certificate check that returns “valid” answers a narrower question than it sounds like: it confirms the cryptographic chain and hostname match hold up today, not that the server configuration is otherwise sound, that the private key hasn’t been separately compromised, or that the TLS versions and cipher suites offered are still considered strong. Treat a passing certificate check as one necessary condition among several, not a complete transport-security audit — see our guide on mail server STARTTLS enforcement for an example of a transport-layer gap that a valid certificate alone does nothing to close.