X.509 / CSR / PEM Inspector
Decode certificates, CSRs, PEM bundles, and private keys locally. Inspect SANs, EKUs, validity windows, chain structure, and key matches without OpenSSL.
Certificates, CSRs, bundles, and private keys are processed locally in your browser in v1. Nothing is uploaded to CodeAva servers automatically, but you should still follow your internal handling policy before pasting sensitive PKI material into any browser tool.
No automatic upload of keys or certs
PEM and DER object detection
SPKI-derived key identity checks
Coverage help, not full TLS validation
Sensitive material note
This inspector intentionally focuses on safe metadata, chain structure, and public-key-derived identity. It does not try to expose more of a private key than the material you already provided.
Primary input
Paste PEM text or upload a DER/PEM file to inspect.
Compare input
Optional second object for side-by-side comparison and match checks.
What is the difference between PEM, DER, CRT, and CER?
DER is a binary ASN.1 encoding. PEM is the text-wrapped Base64 version commonly shown with lines like -----BEGIN CERTIFICATE-----.
.crt and .cer are file extensions, not cryptographic object types. Either extension can contain PEM or DER. On Linux, web-server, and DevOps workflows, PEM is often the more common transport format because it is easy to paste, inspect, and concatenate into bundles.
How do I know if a private key matches a certificate?
A certificate matches a private key when the certificate's public key corresponds to that private key. Older guides often describe this as a modulus comparison, but that is only a useful mental model for RSA.
Modern tooling should use algorithm-aware key consistency checks. For RSA that can still mean modulus and exponent equivalence. For EC and Ed25519-style keys, the right comparison is the derived public key identity itself. This inspector uses a public-key/SPKI-derived identity so the same workflow works across key algorithms.
What can a CSR actually tell you?
A CSR contains subject information, a public key, a signature proving possession of the matching private key, and optional attributes such as an extension request.
SANs, EKUs, key usage, and similar fields inside a CSR are usually requested extensions, not guaranteed final certificate truth. A CA can issue a certificate with different SANs, different EKUs, or additional constraints.
Why SANs matter more than the Common Name
In modern TLS workflows, hostname coverage should be read from the Subject Alternative Name extension first. A matching Common Name on its own is not enough guidance for current browser and platform behavior.
Wildcards and IP coverage also need explicit SAN entries. A certificate can look correct at a glance while still failing because the expected hostname or IP is missing from SANs.
Certificate chain inspection vs trust validation
A visually correct chain is not automatically trusted. Chain inspection can tell you whether issuer/subject linkage looks right, whether basic constraints look plausible, and whether adjacent signatures validate where supported.
Full trust validation depends on trust anchors, path validation rules, platform behavior, hostname matching, revocation handling, and sometimes policy constraints. This tool checks structure, not complete browser trust.
Local processing and privacy
Certificates, CSRs, and especially private keys are processed locally in-browser in v1. There is no automatic upload path for the material you inspect here.
That matters because internal PKI material and private keys are highly sensitive. Local processing reduces exposure, but it does not replace your internal policy. Teams should still decide what can and cannot be pasted into any browser-based tool.
In v1, certificate parsing, CSR inspection, chain analysis, PEM/DER conversion, and key matching all happen in your browser. No certificates, CSRs, private keys, or PEM bundles are uploaded automatically. Because private keys and internal PKI material are highly sensitive, you should still follow your organization's handling policy before pasting them into any browser tool.
Overview
TLS files are notoriously opaque. A pasted certificate bundle or CSR often looks like unreadable Base64 until you reach for OpenSSL, remember the right flags, and translate the output back into deployment decisions. That slows down routine ops work and makes incident response harder than it needs to be.
In production, SAN mismatches, missing intermediates, wrong bundle order, and private-key mismatches regularly cause outages. A certificate can be syntactically valid yet still fail because it does not cover the expected hostname, because the chain is assembled incorrectly, or because the private key on disk does not belong to the certificate being deployed.
Local inspection matters most when the material is sensitive: internal CSRs, staging certs, corporate roots, private keys, and internal PKI bundles. This tool gives you a safer visual workflow for the most common certificate-debugging tasks without sending that material to a server.
What this tool helps with
Practical uses
- Checking certificate expirationreview notBefore / notAfter values, get a prominent expires-in countdown, and catch certificates that are already expired or about to expire.
- Reviewing SANs before deploying or submitting a CSRinspect DNS and IP SANs directly, highlight wildcard names, and see whether the expected hostname appears to be covered.
- Confirming whether a private key matches a certificate or CSRrun an algorithm-aware comparison rather than relying on RSA-only modulus folklore.
- Inspecting PEM bundles and intermediate orderingseparate the leaf, intermediates, and root, then check whether issuer/subject relationships and adjacent signatures line up structurally.
- Converting PEM and DER where appropriatere-encode confidently parsed certificates, CSRs, and public keys without guessing whether a .crt or .cer file contains PEM or DER.
- Replacing common OpenSSL inspection commands with a safer visual workflowdecode the object locally, copy the summary you need, and move on without remembering a chain of shell flags.
What it does not prove
- Treating chain inspection as full trust validationa chain can look structurally correct while still failing trust-anchor, revocation, hostname, or platform-specific path-validation rules.
- Assuming a CSR defines the final issued certificateSANs and EKUs inside a CSR are requested extension data, not guaranteed final certificate contents.
- Expecting every encrypted key to be fully inspectableencrypted private keys are identified safely, but matching and public-key extraction stop until the key is decrypted locally.
How to use
- 1
Paste a PEM block, DER file, CSR, certificate, key, or bundle
Paste PEM text directly or upload a PEM / DER file. The tool detects supported object types locally in your browser.
- 2
Let the tool detect the object type
Before deep decoding, the tool labels whether the input looks like a certificate, CSR, PEM bundle, private key, encrypted key, or public key.
- 3
Review the extracted metadata
Check subject, issuer, validity, SANs, EKUs, fingerprints, and whether the object looks like a CA or end-entity certificate.
- 4
Compare a certificate or CSR against a private key if needed
Use the optional second pane to compare a key, certificate, or CSR with algorithm-aware public-key matching rather than RSA-only heuristics.
- 5
Inspect bundle order if a PEM chain is pasted
When multiple certificates are present, review chain order, issuer/subject linkage, and adjacent signature checks where the browser can evaluate them locally.
- 6
Copy or export the result
Copy a certificate summary, CSR summary, key-match result, chain summary, or converted PEM / DER output for tickets, runbooks, or deployment notes.
Common issues and fixes
Certificate expires soon or is already expired
Check the validity panel first. An expired or near-expiry certificate may still have the right SANs and chain, but it will fail once the client evaluates time validity. Renew or replace it before debugging deeper layers.
SANs are missing the hostname you expected
Modern TLS hostname checks read SANs first. If the expected DNS name or IP address is not present in SANs, the certificate is not the right one for that endpoint even if the Common Name looks plausible.
CSR requests do not match what you intended
Inspect the CSR's requested SANs, EKUs, and key usage before sending it to a CA. If the request is wrong, regenerate the CSR before issuance. Remember that requested extensions are not guaranteed final cert contents.
Private key does not match the certificate
Use the matcher rather than an RSA-only modulus habit. A mismatch means the deployment pair is wrong, even if both files look individually valid. Compare the actual certificate to the exact key file on the target path.
Bundle contains the wrong order
Most servers expect the end-entity certificate first, then intermediates, then an optional root if you intentionally include it. A root-first bundle often imports fine into tools but fails at deployment time.
Assuming chain inspection is the same as browser trust validation
Structural chain checks cover issuer linkage, signature path hints, time validity, and CA constraints where visible. They do not prove trust-store membership, revocation status, or hostname match unless you separately test those conditions.
Assuming modulus comparison works for every key algorithm
That mental model only applies cleanly to RSA. EC and EdDSA objects need an algorithm-aware public-key comparison. This tool matches using public-key identity so the same workflow works across supported key types.
Frequently asked questions
Related tools + guides
Related certificate and transport-layer debugging paths
Working with TLS certificates instead of JWT keys? Use the JWK/JWKS Inspector & JWT Signature Debugger for JSON web keys, or stay here when the material is X.509, CSR, PEM bundle, or server key material.
Securing your endpoint at the application layer? The Webhook Signature Verifier & HMAC Playground helps with request signing, while this inspector helps confirm the transport layer still has the right certificate and key pair behind it.
Header security is only one layer. After validating certificate and key correctness, use the HTTP Headers Checker and CSP Evaluator to review browser-facing policy and deployment hygiene.