Certificate & PKI Inspector
Decode X.509 certificates and CSRs (PEM or DER) right in your browser. Review subject, issuer, validity, SAN, public key, signature, and extensions; check chain order, hostname coverage, and CSR-to-certificate matches—without uploading anything.
- PEM / DER / chain bundles
- CSR ↔ certificate match
- Local-only processing
- No sign-up, free
Files and pasted text are parsed in this browser tab only. Nothing is uploaded, and nothing is stored after you close the tab.
What this tool does and does not verify
This tool performs local structural and cryptographic checks only. It does not query OCSP/CRL services and does not evaluate OS or browser trust stores.
Drop certificates or CSRs here
Drag and drop files, choose them from your device, or paste PEM text below.
Accepted: .pem, .crt, .cer, .der, .csr — PEM bundles with multiple certificates are supported
Up to 32 files, 2 MB each, 8 MB total.
Expiry thresholds
Choose how many days before expiry a certificate should be flagged.
About Certificate & PKI Inspector
Certificate & PKI Inspector is a local workspace for reading and checking X.509 certificates and PKCS#10 certificate signing requests (CSRs). Drop in .pem, .crt, .cer, .der, or .csr files—or paste PEM text—and see every field in plain language: subject, issuer, validity dates, Subject Alternative Names, public key, signature algorithm, extensions, and fingerprints. It also orders a chain you provide, checks whether a hostname is covered, compares a CSR with the certificate issued from it, and produces reports and matching OpenSSL commands.
Everything runs inside your browser tab. Certificates and CSRs are never uploaded, and the tool refuses to process private keys at all. It is not an online SSL checker: it does not connect to your server, and it inspects only the files you give it.
What is an X.509 certificate?
An X.509 certificate binds a public key to an identity—usually a set of hostnames for TLS—and is signed by an issuer, typically a certificate authority (CA). Its core fields are the subject (who the certificate is for), the issuer (who signed it), a serial number, a validity window (Not Before and Not After), the subject's public key, and a signature produced with the issuer's private key.
Extensions add the rules: Subject Alternative Name lists the names the certificate is valid for, Key Usage and Extended Key Usage restrict what it may be used for (server authentication, client authentication, code signing, and so on), Basic Constraints says whether it can act as a CA, and the Authority/Subject Key Identifiers help link a certificate to its issuer. The inspector decodes each of these and shows the raw OID and hex value when you need them.
CSR vs certificate: how to confirm they match
A certificate signing request (CSR, PKCS#10) is what you send to a CA. It contains your public key and the subject and SAN details you are requesting, signed with your private key to prove possession. The CA returns a certificate that should carry the same public key.
A common failure after renewal is installing a certificate that was issued for a different key than the one on the server. Load the CSR and the certificate together and the Compare view checks the public key (by SPKI fingerprint), subject fields, and SAN entries side by side, so you can confirm the pair before deploying. Two certificates can be compared the same way—for example, the old and the renewed one.
Subject Alternative Names and hostname coverage
Browsers and modern TLS clients match the hostname only against the SAN extension. The Common Name (CN) is ignored for this purpose, so a certificate with the right CN but no matching SAN entry will still fail. The SAN tab lists every DNS name, IP address, email, and URI entry.
Enter a hostname or IP address in the hostname check to see whether it is covered by an exact DNS entry, a wildcard (a wildcard such as *.example.com covers exactly one label, so it matches www.example.com but not example.com or a.b.example.com), or an IP entry. This compares names only—it does not connect to the host.
Certificate chains: leaf, intermediate, root
A server normally presents its leaf certificate followed by one or more intermediate certificates. Clients build a path from the leaf up to a root they already trust. A missing or misordered intermediate is one of the most frequent causes of errors that appear on some clients but not others.
Paste a full-chain PEM bundle or drop the files together and the Chain view orders them from leaf to root by matching issuer and subject names and AKI/SKI identifiers. It points out missing issuers and incorrect input order, and can optionally verify each link's signature using the issuer's public key. Only the certificates you supply are used; nothing is fetched from AIA URLs.
Expiration monitoring with adjustable thresholds
Each certificate is classified as within its validity period, expiring soon, expired, or not yet valid, along with the number of days remaining. You can set your own notice, warning, and critical thresholds (30, 14, and 7 days by default) to match your renewal policy.
Validity is evaluated against this device's clock. If the device time is wrong, the result will be too, so the evaluation time is always shown next to the status.
What is verified—and what is not
Checked locally: certificate and CSR structure, validity dates, SAN hostname coverage, issuer/subject and key-identifier links between the certificates you provide, optional link signatures, public key and signature algorithm observations, and CSR-to-certificate key match.
Not checked: whether the root is trusted by your operating system, browser, or runtime trust store; revocation status via OCSP or CRL; which certificate a live server actually serves; Certificate Transparency log inclusion; and CA/Browser Forum policy compliance. A structurally valid chain is therefore not the same as a chain your users' browsers will trust. Diagnostics are guidance and may not detect every certificate, PKI, hostname, or trust-store issue.
Privacy: local processing and private key rejection
Parsing, hashing, signature verification, and report generation all run in your browser with the Web Crypto API. Nothing is sent to a server, and nothing is saved to local storage or IndexedDB—closing the tab discards everything.
Certificates and CSRs are public by design, but private keys are not. If an input contains a PRIVATE KEY block (PKCS#8, RSA, EC, DSA, encrypted, or OpenSSH), the tool stops and discards it rather than parsing it, and tells you what was rejected.
Reports, conversions, and OpenSSL commands
Download the results as JSON for automation, CSV for spreadsheets, or a standalone HTML report for tickets and audit records; PEM data can be included or left out. Convert certificates between PEM and DER, and the tool re-parses the output to confirm the subject, issuer, serial, and fingerprint did not change.
The OpenSSL tab lists equivalent openssl x509, req, and verify commands so you can reproduce each check on your own machine. The commands are generated as text only; nothing is executed from the page.
Frequently asked questions
Are my certificates or CSRs uploaded to a server?
No. All parsing and checks run inside your browser tab. The files never leave your device and nothing is stored after you close the tab.
Can this check my live website's SSL certificate?
No. This is not an online SSL checker and it does not connect to any server. Export the certificate from your server or browser (or copy the PEM your server is configured with) and inspect that file here.
Does it tell me whether a certificate is trusted by browsers?
No. The tool does not evaluate your OS or browser trust store. It can confirm that a chain you supply is structurally linked and, optionally, that each link's signature verifies—but trust depends on which roots a client has installed.
Does it check revocation with OCSP or CRL?
No. Revocation checks require contacting the CA's OCSP responder or downloading a CRL, and this tool makes no network requests. The report explicitly marks revocation as not checked.
What happens if I accidentally paste a private key?
The tool detects PRIVATE KEY blocks and refuses to process them. The content is discarded and you are shown which input was rejected. If the key may have been exposed elsewhere, consider rotating it.
Which file formats are supported?
PEM and DER encoded X.509 certificates and PKCS#10 CSRs, typically with .pem, .crt, .cer, .der, or .csr extensions. PEM bundles containing several certificates (such as fullchain.pem) are split and analyzed together. PKCS#12 (.pfx/.p12) files are not supported because they usually contain private keys.
How do I check that a CSR matches the issued certificate?
Load both the CSR and the certificate, then open the Compare tab. It compares the public keys by SPKI fingerprint and lists subject and SAN differences. If the public keys differ, the certificate was issued for a different key pair.
Why does my certificate fail even though the Common Name is correct?
Modern clients ignore the CN for hostname matching and use only the Subject Alternative Name extension. Check the SAN tab and run the hostname check; if the name is not listed there, the certificate needs to be reissued with that SAN.
Why is my chain reported as incomplete?
The issuer of at least one certificate was not found among the files you provided. Add the missing intermediate certificate from your CA. Roots are often omitted on servers, so a chain ending at an intermediate is common; the tool shows exactly which issuer is missing.
How is the expiry status calculated?
The Not Before and Not After dates are compared with this device's current time. You can adjust the notice, warning, and critical thresholds in days. If the device clock is wrong, the result will be wrong too.