Decode and inspect certificate validity, subject and issuer names, public-key details, SANs, key usage, extensions, fingerprints, and basic pasted-chain relationships without uploading the certificate bundle.
Security reminder. Certificates are public data, but private keys are secrets. Do not paste production private keys. If a private-key PEM block is detected, this tool identifies the block type but intentionally does not parse, display, copy, or export the private-key bytes.
Certificate decoder & inspector
Paste a certificate or PEM bundle to decode
Supports PEM certificate blocks and base64 DER certificate input. Decoding and inspection remain in the browser. The tool performs structural inspection only and does not verify signatures, revocation, trust anchors, or complete TLS service identity.
Multiple certificates can be pasted together. Other PEM block types are identified where possible.
No certificate loadedPaste a certificate or PEM bundle and click Inspect certificates.
SAN hostname checkEnter a DNS name or IP address to check against a selected certificate.
Certificate
Inspection notes
Text report
Inspect certificates to generate a local text report.
FAQ
Certificate decoder and inspector questions
Does this validate that a certificate is trusted?
No. It parses certificate fields and performs practical local checks. It does not verify the certificate signature, build a trusted path against an operating-system or browser trust store, check OCSP/CRLs, or establish that a TLS service is trustworthy.
What happens if I paste a private key?
The page identifies common private-key PEM block types and shows a warning. It intentionally does not parse, display, copy, include, or export the private-key bytes in the inspection report.
What does the hostname check do?
It compares the entered DNS name or IP address against parsed Subject Alternative Name entries. DNS wildcards are limited to a complete left-most label. It is a debugging aid, not complete TLS identity verification.
Can I inspect a certificate chain?
Yes. Paste multiple certificate blocks. The tool compares issuer and subject names and, when present, Authority Key Identifier and Subject Key Identifier values. It does not cryptographically verify the chain signatures.
Is certificate data uploaded?
No. Parsing and fingerprint calculation run in your browser. The page does not upload or save the pasted input.
Practical guide
Read certificate identity, purpose, and chain relationships
An X.509 certificate binds a public key to names and attributes signed by an issuer. The inspector decodes pasted PEM certificates locally so that validity periods, subject and issuer details, key usage, extensions, fingerprints, and likely bundle relationships can be reviewed without sending the certificate text to a server.
Check these fields first
Validity: confirm the current time is between Not Before and Not After.
Subject and SAN: identify the organisation, service, DNS names, or other names represented.
Issuer: identify which certificate authority signed the certificate.
Basic Constraints: distinguish end-entity certificates from CA certificates.
Key Usage and Extended Key Usage: check whether the certificate is intended for signing, server authentication, client authentication, or another purpose.
Recommended workflow
Paste only public certificate PEM blocks, not private keys or passwords.
Identify the end-entity certificate used by the application or server.
Compare its issuer with the subject of the next certificate in the bundle.
Continue through intermediate certificates toward a trusted root.
Compare fingerprints when confirming that two systems hold the same certificate.
Worked example
Understand a simple certificate chain
Leaf certificate
Subject: CN=api.example.test
Issuer: CN=Example Issuing CA 01
Intermediate certificate
Subject: CN=Example Issuing CA 01
Issuer: CN=Example Root CA
The matching leaf issuer and intermediate subject indicate a likely parent relationship, but name matching alone is not cryptographic chain validation. A complete validator also checks signatures, constraints, path length, policy, trust anchors, current time, revocation information, and the intended hostname or application identity.
Troubleshooting
Common certificate failures
Frequent causes
The certificate is expired or not yet valid because of renewal timing or clock skew.
The hostname is absent from the Subject Alternative Name extension.
An intermediate CA certificate is missing from the server's presented chain.
The certificate has the wrong extended key usage for server or client authentication.
The application is configured with an old certificate or a certificate whose private key does not match.
Privacy and limitations
Public certificates are designed to be shared, but private keys, PKCS#12 passwords, API secrets, and confidential configuration must never be pasted into a public tool.
The inspector does not use the operating system trust store, contact revocation services, perform a live TLS handshake, or prove that a private key is available. Treat the decoded fields as diagnostic evidence, not a complete trust decision.
Related guides
Continue with the underlying concepts
Use these guides when the tool exposes a structure or error that needs a standards-level explanation.
PKI and XML security
PEM and X.509 Certificate Chains
Identify certificate blocks, order chains and separate trust, hostname and private-key checks.
Practical guidance backed by integration experience
Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.
These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.