X509 Certificate Inspector
Inspect X.509 certificate fields, extensions, and metadata details.
X.509 Certificate Inspector
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The X.509 Certificate Inspector reads the extension fields of an X.509 certificate — the parts of the structure that go beyond the basic subject, issuer, and validity dates already covered by the PEM Certificate Decoder. X.509 v3 (the version in universal use today) added an extensible mechanism for attaching additional, purpose-specific metadata to a certificate, and it's these extensions — not the core fields — that actually determine what a certificate is trusted to do and how a relying party should treat it.
- Four extensions matter most in day-to-day certificate work: the Subject Key Identifier (SKI), a hash of the certificate's own public key used to reference it unambiguously; the Authority Key Identifier (AKI), the same kind of hash but identifying the issuing CA's key, which is how chain-building software matches a certificate to its issuer without relying on name matching alone; Subject Alternative Name (SAN), the list of hostnames (or IPs, email addresses) the certificate is actually valid for; and Basic Constraints, which declares whether the certificate is allowed to sign other certificates (a CA) or not (an end-entity leaf certificate).
- This tool is the natural next step after the PEM Certificate Decoder for anyone debugging a trust or hostname-matching problem — the basic fields tell you who issued a certificate and when it expires, but the extensions tell you what it's actually trusted to secure and how it fits into a certificate chain.
How It Works
- The certificate's extension block is parsed separately from its core fields (subject, issuer, validity, serial number, which the PEM Certificate Decoder already surfaces).
- The Subject Key Identifier and Authority Key Identifier are extracted and displayed as their hex-encoded hash values — the two identifiers a chain-building algorithm compares to link a certificate to its issuer.
- The Subject Alternative Name list is extracted as the full set of hostnames (and other identity types) the certificate is valid for — this is the list a browser or client actually checks against the hostname it's connecting to, not the Subject field's Common Name.
- Basic Constraints and Key Usage are read to determine whether the certificate is a CA certificate (can sign others) and what cryptographic operations its key is authorized for (digital signature, key encipherment, certificate signing, and similar).
Usage
- Paste the PEM-formatted X.509 certificate you want to inspect.
- Run the inspection to extract the extension fields.
- Review the Subject Key Identifier and Authority Key Identifier to understand this certificate's position in a chain.
- Check the SAN list against the actual hostname you expect the certificate to secure, and the Basic Constraints/Key Usage fields against how the certificate is being used.
Examples
- Inspecting a multi-domain certificate to confirm every hostname a service actually serves is present in its SAN list, not just the primary domain in the Subject field.
- Comparing an intermediate CA certificate's Subject Key Identifier against a leaf certificate's Authority Key Identifier to confirm they're meant to chain together.
- Checking Basic Constraints on a certificate before configuring it as a trusted root in an internal tool, to confirm it's actually a CA certificate and not an end-entity leaf.
- Reviewing Key Usage flags on a certificate presented for client authentication to confirm it's actually authorized for that purpose rather than only server authentication.
Real-World Use Cases
- Diagnosing a hostname-mismatch TLS error by checking the actual SAN list rather than assuming the Subject Common Name is what a browser checks against.
- Confirming whether a given certificate is a CA certificate (Basic Constraints CA:TRUE) before trusting it to sign other certificates in an internal PKI setup.
- Matching a leaf certificate to the correct intermediate in a chain by comparing the leaf's Authority Key Identifier against candidate intermediates' Subject Key Identifiers.
- Auditing Key Usage and Extended Key Usage flags to confirm a certificate is actually authorized for the operation it's being used for (e.g. server authentication versus code signing).
Best Practices
- Always check the SAN list, never the Subject Common Name alone, when confirming which hostnames a certificate actually covers — modern clients ignore the CN for hostname matching if a SAN extension is present.
- Use the Authority Key Identifier / Subject Key Identifier pair, not issuer/subject name string matching, when you need to programmatically confirm which intermediate a leaf certificate chains to.
- Treat Basic Constraints CA:TRUE as a high-trust signal — a certificate with this flag can mint other trusted certificates, so verify it's genuinely meant to be a CA before trusting it as one.
- Cross-check Key Usage and Extended Key Usage against the actual operation being attempted; a certificate valid for one purpose (e.g. digital signatures) is not automatically valid for another (e.g. server authentication).
Common Mistakes
- Assuming the Subject Common Name is what determines hostname validity — modern TLS clients check the SAN extension and ignore the CN entirely when a SAN is present, per RFC 6125's guidance and current browser behavior.
- Treating issuer/subject name matching as sufficient for chain-building — two different CAs can legitimately use similar-looking names; the AKI/SKI hash comparison is what actually disambiguates them.
- Overlooking Basic Constraints entirely and trusting any certificate presented as if it could be a CA — a leaf (end-entity) certificate with CA:FALSE cannot legitimately sign other certificates, and software that fails to check this is exploitable.
- Confusing Key Usage (what cryptographic operations are permitted) with Extended Key Usage (what higher-level purposes, like server or client authentication, the certificate is scoped for) — a certificate can satisfy one without the other.
Limitations
- This tool reads the extension fields present in a certificate you provide; it does not verify the certificate's signature or its position in a real trust chain — use the SSL Certificate Chain Validator for chain-order and trust verification.
- Extension presence and content are only as accurate as what the issuing CA actually populated — a poorly-configured CA can omit extensions modern clients expect, and this tool reports what's there, not what should be.
- This is an inspection tool for certificates you already have; it does not fetch or verify certificates against live servers or revocation services.
Technical Reference Guide
- X.509 v3 and its extension mechanism, including Subject Key Identifier, Authority Key Identifier, Subject Alternative Name, Basic Constraints, and Key Usage, are defined by RFC 5280, Section 4.2.
- The rule that SAN takes precedence over the Subject Common Name for hostname verification is specified in RFC 6125.
- Extended Key Usage, which further scopes a certificate to specific purposes like TLS server or client authentication, is defined in RFC 5280 Section 4.2.1.12.
FAQ
What's the difference between this tool and the PEM Certificate Decoder?
The PEM Certificate Decoder surfaces the core fields — subject, issuer, validity dates, serial number, signature algorithm. This tool focuses on the X.509 v3 extensions specifically: SAN, Basic Constraints, Key Usage, and the SKI/AKI identifier pair, which determine what the certificate is actually trusted to do.
Why does my browser show a hostname mismatch even though the certificate's Subject shows the right domain?
Modern clients check the Subject Alternative Name extension, not the Subject Common Name, when a SAN is present. If the domain you're connecting to isn't listed in the SAN, the CN alone won't satisfy hostname verification.
What does Basic Constraints CA:TRUE mean?
It means the certificate is authorized to sign other certificates — it's a CA certificate, not an end-entity leaf. Software that builds or validates chains should never accept a CA:FALSE certificate as an issuer.
How do Subject Key Identifier and Authority Key Identifier relate to each other?
A certificate's Authority Key Identifier should match its issuer's Subject Key Identifier. Chain-building software uses this hash-based match, rather than issuer/subject name comparison, to reliably link a certificate to the correct parent in a chain.
What's the difference between Key Usage and Extended Key Usage?
Key Usage restricts the low-level cryptographic operations a certificate's key may perform (e.g. digital signature, key encipherment). Extended Key Usage further restricts the certificate to specific higher-level purposes, like TLS server authentication or code signing.
Does this tool verify that the certificate is trusted?
No — it inspects and reports the extension fields present in the certificate you provide. Verifying trust requires validating the full chain up to a trusted root, which is what the SSL Certificate Chain Validator is for.
Part of this Developer Hub
This utility is part of our comprehensive Certificate & PKI topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Certificate & PKI Lab workshop for complementary engineering workflows.