When to Decode a Certificate
Certificate errors in browsers and APIs are often opaque. Decoding the raw certificate reveals the actual values and makes diagnosis straightforward. Common reasons to inspect a cert:
- Expired: check the "Not After" field directly instead of inferring from the browser message.
- Wrong domain: the Subject Alternative Names (SANs) list every hostname the cert covers. If your domain is missing, that is why the handshake fails.
- Wrong issuer: if a cert chain is broken, the issuer field will point to an intermediate or root that is not trusted by the client.
Key Fields to Understand
- Subject / CN: the primary domain name (largely superseded by SANs in modern certs).
- Subject Alternative Names: the definitive list of covered hostnames and IPs.
- Validity period: "Not Before" and "Not After" dates.
- Issuer: the CA that signed the cert.
- Key usage / Extended key usage: what the cert is permitted to be used for (TLS server auth, code signing, etc.).
- Serial number: unique identifier, useful when checking revocation lists.
Common Debugging Scenarios
A wildcard cert (*.example.com) does not cover the apex domain (example.com) — add it as a SAN. An internal service using a self-signed cert will fail in clients that do not have the root CA in their trust store. Decoding the cert confirms which root is required.