PKI Viewer — Manual

Back to overview: PKI Viewer · Open the live tool: www.jpkc.com/tools/pki/

This manual describes the PKI Viewer in full: the four tabs, every recognised file format, which fields a certificate reveals and how to read them, how the signature, chain, and key checks work, and the tool's deliberate limits. The interface is in English, so the labels appear here exactly as you'll find them in the tool.

Interface layout

The PKI Viewer is organised into four tabs:

File Analyzer — analyse files via drag-and-drop or a file picker (binary or PEM).
PEM Decoder — paste PEM-encoded text or bare Base64; the output builds up while you type.
Help — supported formats, capabilities and limits, a few tips.
Reference — a lookup: file extensions, certificate fields, OpenSSL commands, trust model.

The first two tabs are the working areas, the last two pure documentation. Each working area has its own results section — a result in one tab stays put while you work in the other. A notice banner at the bottom of the page reiterates that everything stays in the browser and that the HTML preview of emails blocks remote images. On narrow screens (below 576 pixels) field names and values in the result tables are stacked.

The "File Analyzer" tab

This is where you analyse files. There is a large drop zone reading "Drag & drop a file here", with a Browse Files button inside it for the classic file dialog. The drop zone works from the keyboard too: focus it and press Enter or Space to open the dialog. The extensions listed there (.pem .crt .cer .der .p7b .p7m .p7s .p12 .pfx .csr .crl .key .pub) are only a guide — the tool detects the type from the content, not the file name. A file can be up to 50 MB; larger ones are rejected with a message. PEM text and bare Base64, however, are only detected within the first 4 MB of a file (see Limits and privacy).

The file is read as binary and detected automatically, in this order:

If the content contains -----BEGIN …, it is processed as PEM — each block on its own, as in the PEM Decoder.
If it consists only of Base64 without PEM lines (at least 64 characters), the Base64 is decoded and processed as DER. A typical case is .p7m files saved as text, such as electronic invoices.
Otherwise the file is read as DER/BER (binary) and classified by its ASN.1 structure: PKCS#7/CMS, PKCS#12, certificate, CSR, revocation list (CRL), private key (PKCS#8, encrypted PKCS#8, SEC1, PKCS#1), or public key (SPKI, PKCS#1). BER with indefinite lengths is read as well.
If it's valid ASN.1 but none of those, the tool says so honestly ("Valid ASN.1, but not a recognised certificate, key, CSR, CRL, PKCS#7 or PKCS#12 structure."). If nothing can be read at all, the results section shows "Cannot read this input:" followed by the reason.

Example and Clear

Above the results area there are two controls:

The Example dropdown loads bundled sample files, grouped into two sections:
- Certificates: ECDSA chain (leaf → intermediate → root) — a three-link chain with EC keys and an RSA root; RSA certificate + CA — the end-entity certificate www.example.com plus its root CA; PKCS#12 (password: example) — a container the tool opens right away with the password example.
- Signed files (P7M): Signed text document, three S/MIME emails (text + HTML + PDF, text + PDF, HTML + 2 attachments), MIME without e-mail headers, MIME starting with a boundary, and Plain text (not an e-mail).
Clear empties the results area and the password field and hides the password row.

PKCS#12 password

When the File Analyzer detects a PKCS#12 container — whether the file is called .p12, .pfx, or something else entirely — it reveals a PKCS#12 Password row with a password field and an Open button; the results area says "Enter its password above.". You enter the container password and click Open (or press Enter). If it's correct, the contained certificates and private keys are shown; if not, a notification says "Wrong password." and the password field stays selected for another attempt. Other errors while opening appear as "PKCS#12 error: …". Current containers with AES encryption are supported as well as legacy formats.

The "PEM Decoder" tab

This tab takes PEM-encoded text in a large input area — certificates, chains, CSRs, CRLs, keys, PKCS#7 — or Base64 without PEM lines. The output appears while you type or paste (shortly after your last keystroke); the Decode button triggers the evaluation manually as well and reports "Please paste PEM-encoded data first." if the field is empty. An Example button loads a self-signed sample certificate for example.com, Clear empties input and output.

The decoder recognises what it's dealing with from the markers:

CERTIFICATE, X509 CERTIFICATE, TRUSTED CERTIFICATE → certificate; any number of blocks are rendered individually and linked into a chain.
PKCS7, CMS, PKCS #7 SIGNED DATA → PKCS#7/CMS container.
CERTIFICATE REQUEST, NEW CERTIFICATE REQUEST → CSR.
X509 CRL → revocation list.
PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY → private key; ENCRYPTED PRIVATE KEY and blocks with Proc-Type: 4,ENCRYPTED → encrypted private key.
PUBLIC KEY, RSA PUBLIC KEY → public key.

A few more types are recognised but can't be displayed, and the tool says so ("Recognised: … This tool cannot show it."): DH PARAMETERS, EC PARAMETERS, DSA PRIVATE KEY, OPENSSH PRIVATE KEY (with a hint to convert the key using ssh-keygen -p -m PEM -f key), PGP PUBLIC KEY BLOCK, and PGP MESSAGE. Unknown markers are reported as "Unknown PEM type". The PEM Decoder doesn't accept PKCS#12 containers — it points you to the File Analyzer instead.

Hand-over from the SSL checker

The SSL checker in the "DNS, SSL, Redirect & URL" tool has a PKI Viewer button in its Certificate Chain card. It opens the PKI Viewer in a new tab, switches to the PEM Decoder, inserts the chain the server delivered, and evaluates it straight away ("Certificate chain from the SSL checker loaded."). The hand-over goes through your browser's local storage; the PKI Viewer deletes the entry as soon as it has read it.

Results summary and messages

Above the result cards there's a summary such as "Found 3 certificates, 1 private key." — it counts certificates, private and public keys, CSRs ("signing requests"), revocation lists, and signed messages. Certificates and revocation lists from a PKCS#7 container are included and also feed into the chain and key checks.

The cards follow a fixed order: signed content first (email or document, then the signatures), then the chain and the certificates. After that come CSRs, keys, revocation lists, and notices in the order of the input; revocation lists from a PKCS#7 container come last. Blocks that can't be read show up as a yellow or red notice card with their PEM label and the reason — the remaining blocks of the input are still displayed.

What a certificate card shows

For every detected certificate the tool renders a card. The header shows the Common Name of the subject (numbered #1, #2 … when there are several certificates; for PKCS#12 also the stored display name), plus these badges as applicable:

Self-signed — subject equals issuer and the self-signature is valid.
Private key included — a private key in the same input belongs to this certificate.
CA — a CA certificate according to Basic Constraints.
the validity status (see Not Before / Not After).

In the table below:

Subject and Issuer

The distinguished names of the holder (Subject) and the issuer (Issuer), assembled from components such as CN, O, OU, C, ST, L, E, DC, serialNumber, or organizationIdentifier, in the order the certificate uses. If subject and issuer are identical, "(same as subject)" follows the issuer.

Serial Number

The serial number as an uppercase hex string with colons as separators (e.g. 30:41:91:13:75:…), without leading zero bytes.

Version

The X.509 version of the certificate — these days practically always v3.

Not Before / Not After

The validity period in the format 2026-03-16 08:19:38 UTC. Not After is followed by the remaining lifetime ("N days left"), for expired certificates "expired N days ago", for those not yet valid "valid from …". The badge in the card header shows the status; for Valid, Expires in N days, and Expired the Not After date is coloured to match:

Valid (green) — valid and more than 30 days from expiry.
Expires in N days (yellow) — expires within the next 30 days.
Expired (red) — expiry date already passed.
Not yet valid (grey badge, date not coloured) — the start of validity is still in the future.

Signature Algorithm

The signature algorithm, translated from its OID. Recognised values include MD5/SHA-1/SHA-224/SHA-256/SHA-384/SHA-512 with RSA, RSA-PSS (with hash, MGF1 hash, and salt length), ECDSA with SHA-1/224/256/384/512, Ed25519, Ed448, and DSA. SHA-1 and MD5 signatures get a yellow weak badge. If the OID is unknown, the tool shows it as the raw digit sequence.

Signature

This row holds the result of the signature check. The tool looks for the certificate's issuer in the same input (or, for a self-signed certificate, uses the certificate itself) and verifies the signature with the browser's Web Crypto API:

valid — the signature comes from the key of the named issuer, followed by e.g. "(by #2 Example ECC CA E1)" or "(self-signed)". With SHA-1 you also get the note SHA-1 (weak).
invalid — the signature doesn't match; in some cases with a reason, for instance when an ECDSA-signed certificate would be checked against an RSA key.
not checked — with a reason, e.g. "Issuer certificate not included — not checked." or because the browser doesn't support the scheme.

Checkable are RSA (PKCS#1 v1.5) with SHA-1/256/384/512, RSA-PSS as long as hash and MGF1 hash are the same, ECDSA on P-256, P-384, and P-521, and Ed25519 if the browser supports it. Not checkable are MD5, SHA-224, Ed448, DSA, and the brainpool and secp256k1 curves — the Web Crypto API doesn't know them. The check requires an HTTPS connection, because browsers only provide Web Crypto there.

Public Key

The type and size of the public key: for RSA and RSA-PSS the bit length plus exponent (e.g. RSA 2048 bit (e = 65537)), for EC the curve (e.g. EC P-256 (prime256v1), also secp256k1 and the brainpool curves), plus Ed25519, Ed448, X25519, X448, DSA, and DH.

SHA-1 and SHA-256 Fingerprint

Two fingerprints over the certificate's original bytes (DER), as uppercase hex strings with colons. Each has a copy button next to it. The fingerprint is the most practical value for confirming beyond doubt that two certificates are identical.

Public Key Pin

The public key pin in the format pin-sha256="…": the Base64-encoded SHA-256 hash of the public key (SubjectPublicKeyInfo), with a copy button. Unlike the fingerprint, it stays the same when a certificate is reissued with the same key — useful for certificate pinning in apps, or for checking whether a renewed certificate still uses the old key.

Subject Alt Names

If present, the Subject Alternative Names as badges, prefixed by type with DNS:, IP: (IPv4 and IPv6 in readable short form), Email:, URI:, DirName:, otherName: (such as the Windows UPN), or RID:. For TLS server certificates this is where the covered hostnames appear.

Key Usage and Extended Key Usage

The bits set in the Key Usage extension (e.g. digitalSignature, keyEncipherment, keyCertSign, cRLSign) and the Extended Key Usage (e.g. serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, smartcardLogon, documentSigning), each as badges. If an extension is marked critical, it's followed by a critical badge — for Subject Alt Names, Key Usage, Extended Key Usage, Basic Constraints, and the remaining extensions under Other Extensions. For the key IDs, Authority Info Access, CRL Distribution Points, Certificate Policies, Certificate Transparency, and TLS Feature the tool doesn't show the critical flag.

Basic Constraints

Whether the certificate is a CA certificate (CA: Yes/No) and, if set, the path length constraint (path length: 0 …).

Key identifiers, AIA, CRL distribution points and policies

Subject Key ID and Authority Key ID — the key identifiers as hex strings. The tool uses them to pair certificates with their issuers in a chain.
Authority Info Access — the URLs of the OCSP responder (OCSP) and of the issuer certificate (CA Issuers).
CRL Distribution Points — the URLs where the issuer's revocation list lives.
Certificate Policies — the policy OIDs, well-known ones with a name such as Domain Validated (DV), Organization Validated (OV), Extended Validation (EV), or the Let's Encrypt policy, plus the CPS URL where present.

The tool only displays these addresses; it never fetches them.

Certificate Transparency, TLS Feature and other extensions

Certificate Transparency — the number of embedded signed certificate timestamps (SCTs), e.g. "2 signed certificate timestamps".
TLS Feature — such as status_request (OCSP Must-Staple).
Other Extensions — all remaining extensions with name (if known) and OID, e.g. name constraints, qualified certificate statements, or Microsoft certificate templates.

PEM export

The footer of each card offers Show PEM (expands the PEM block), Copy PEM (copies the individual certificate as PEM), and Download .crt (saves it as a file named after the common name). That lets you pull a single certificate out of a chain, for instance. CSR, key, and CRL cards have the same three buttons, each with a matching file extension (.csr, .pem, .crl) — except the card for encrypted private keys, which has no PEM export.

Certificate chain

If the input contains more than one certificate, the Certificate Chain card appears ahead of the certificate cards. The tool looks for each certificate's issuer among the others: the issuer DN has to match the subject DN, and where present, the authority and subject key IDs have to agree. The list shows a jump link to each certificate's card, followed by:

"issued by #N …" with the result of the signature check,
"self-signed root" (or "self-signed") for self-signed certificates,
"issued by … (not included)" if the issuer isn't part of the input.

Below that, the tool rates the order: "Order: leaf first, each certificate followed by its issuer." in green if the end-entity certificate comes first and each following one issued the previous one — that's what many servers and clients expect. Otherwise it warns in yellow "Not in the usual order …". If an issuer is missing, it points out that it isn't checked and that a root usually doesn't need to be sent anyway. Only the signatures between the certificates shown are checked; whether you trust the root and whether a certificate has been revoked is left out.

PKCS#7 / CMS and P7M content

For a PKCS#7 or CMS container (.p7m, .p7s, .p7b, .p7c, as PEM, DER, BER, or bare Base64), the tool first shows the signed content and the signatures, then the contained certificates as cards and any revocation lists it carries. You recognise a pure certificate bundle (P7B/P7C) without a signature by the absence of a signature card — only the contained certificates appear (with a chain card from two upwards); a completely empty container is reported as such.

If the container holds content that isn't an email, the Signed content card appears. The tool recognises the type by magic bytes: PDF, XML, HTML, ZIP (including Office/OOXML), legacy MS Office files, PNG, JPEG, and GIF; everything else is classified as text or binary data. It shows the type with its MIME type, the size, and the file name for the download — the source file's name without .p7m/.p7s/.p7c/.p7b, with a matching extension added if needed. For text, XML, and HTML there's also a preview of the first 4000 bytes. The Download button saves the content.

Encrypted CMS messages (envelopedData, authEnvelopedData) are not opened. Instead, the tool explains that they can only be opened with the recipient's private key (mail client or openssl cms -decrypt) and, for envelopedData, states the number of recipients. Other CMS types apart from SignedData, such as encryptedData, are reported as not supported in a yellow notice card.

Signature check (Signature)

The Signature card (Signatures (N) when there are several signers) lists for each signature:

Signer — the signer's certificate with common name and DN, linked to its card.
Signing Time — the time stated by the signer, explicitly labelled "(claimed by the signer)".
Algorithm — hash and signature scheme.
Status — valid with "content unchanged since signing", invalid, with a reason where available (such as "The content was changed after signing (message digest does not match).") or not checked with a reason (e.g. "The signer's certificate is not included.").

To get there, the tool compares the hash of the content with the signed hash value and verifies the signature with the signer's public key. It looks for the signer's certificate only among the certificates inside the container itself, not in the rest of the input. RSA, ECDSA, and Ed25519 signatures can be checked, with the same restrictions as for certificates. "Valid" means: the content is unchanged and was signed with the key of the certificate shown. Whether you trust that certificate (trust store, revocation status) is not checked.

Detached signatures

With a detached signature (typically .p7s), the signed content lives in a separate file. The status then initially reads "needs the signed file", and a note "Detached signature — the signed file is separate." offers the Select the signed file to verify button. Pick the original file and the tool verifies the signature against it, confirming with "Checked against …". This file doesn't leave your browser either.

Embedded MIME email

If the signed content looks like a MIME email (headers such as From:/To:/Subject:, a multipart/ content type with a boundary, or MIME text that starts directly with a boundary), the tool breaks it out:

E-mail message — the headers From, To, Cc, Subject, Date, and Message-ID; encoded headers (RFC 2047) are decoded. The card title shows the number of attachments, and the Original (.eml) button downloads the raw MIME source as an .eml file.
Text body — the text part with a Copy button.
HTML body — the HTML part as source; Preview switches to a rendering in an isolated sandbox iframe (back with Source), Copy copies the source. Embedded images (cid:) appear directly in the preview. Remote images are blocked, because fetching them would tell the sender that — and when — you opened the message, along with your IP address. If the email contains such images, the preview shows a note and a Load remote images button that fetches them only at your explicit request.
Attachments — each attachment individually with name, type, size, and "inline" where applicable, plus a Download button; quoted-printable and Base64 are decoded along the way.

Every part is decoded with the character set it declares; file names per RFC 2231 (such as filename*=UTF-8''…) and names with spaces are read correctly, so accented and other non-ASCII characters come out right.

PKCS#12 / PFX, CSR, and keys

PKCS#12 / PFX: after you enter the password (see PKCS#12 password), the contained certificates and private keys are shown, each with its display name (friendlyName) if one is stored. If a key belongs to one of the certificates, both cards say so.
CSR (PKCS#10): the Certificate Signing Request card shows the subject, the public key (all types, as for certificates), the signature algorithm, the result of the signature check — a valid status proves that the requester holds the matching private key —, the public key pin, further attributes (a challengePassword only as "(set)"), and the requested extensions such as Subject Alternative Names, Key Usage, or Extended Key Usage. Export as PEM or Download .csr.
Private key: the Private Key card states type and size (RSA, RSA-PSS, EC, Ed25519 …), the Format (PKCS#8, PKCS#1, or SEC1), and under Matching Certificate the result of the key match: "matches" with a link to the matching certificate, "matches none of the certificates", "No certificate in this input — add it to check the pair.", or — rarely — "Could not derive the public key in this browser.". The comparison uses the public part (RSA modulus, EC point, Ed25519 key); if the key file lacks it, the tool derives it via the Web Crypto API. The footer warns "Private key — keep it secret" and offers PEM export and Download .pem.
Public key: the Public Key card shows type and size, the format (SPKI or PKCS#1), and the public key pin with a copy button; export as PEM or Download .pem.
Encrypted private key: the Encrypted Private Key card decrypts nothing, but names the protection scheme under Protection — for PBES2 something like PBKDF2 (HMAC-SHA256, 2,048 iterations) + AES-256-CBC, as well as the older PKCS#12 PBE (SHA-1 + 3DES) and classic OpenSSL PEM encryption with its cipher. To inspect the key, it suggests decrypting it locally and deleting the plain copy afterwards:

openssl pkey -in key.pem -out key-plain.pem

Revocation lists (CRL)

The tool shows a certificate revocation list (PEM X509 CRL or DER, also inside a PKCS#7 container) with issuer, version, CRL Number, This Update, Next Update, and signature algorithm. Once the next update time has passed, the Next update overdue badge appears. The Signature row verifies the list's signature if the issuer certificate is part of the same input — otherwise the tool reports that it's missing and leaves the signature unchecked.

Under Revoked you'll find the number of revoked certificates, followed by a table of serial number, revocation date, and reason (keyCompromise, superseded, cessationOfOperation …), up to 500 rows, with the rest summarised as "… and N more.". If a certificate from the same issuer is part of the input and its serial number is on the list, the row is highlighted in red and labelled with the certificate's name. That only applies to the 500 rows shown: a hit further down a large CRL stays unmarked. That's how you check a downloaded CRL against a certificate by hand; the tool itself never downloads CRLs.

The "Help" tab

Pure in-tool documentation: a table of Supported Formats (extension, format, description — from .pem via .p7m/.p7s/.p7b/.p7c to .key/.pub and .crl), a list each of What This Tool Can Do and What This Tool Cannot Do, plus Tips — such as how to export a certificate from your browser (padlock icon in the address bar → certificate details → export as .pem/.crt) and useful OpenSSL commands.

The "Reference" tab

A compact lookup: a table of common PKI file extensions with standard, encoding, and typical content (including .ca-bundle and the unsupported Java KeyStore .jks); a certificate field reference (DN components with OIDs, and the most important X.509v3 extensions such as SAN, Key Usage, Basic Constraints, Authority/Subject Key Identifier, CRL Distribution Points, Authority Information Access, Certificate Policies); a collection of OpenSSL commands for viewing, converting, verifying, and fingerprinting; and a short explanation of the PKI trust model (root CA → intermediate CA → end-entity).

Limits and privacy

Fully client-side: a dedicated parser built on node-forge (opens in a new tab) reads the files in the browser, and the Web Crypto API verifies the signatures. There is no server that receives files and no API. Certificates, private keys, and PKCS#12 passwords never leave your device — verifiable in the Network tab. The only things loaded from the server are the sample files from the Example menu. The browser contacts third-party servers only if you explicitly click Load remote images in an email's HTML preview.
Inspection only, no generation: the tool signs and generates nothing — no certificates, no keys, no CSRs.
No trust decision: it checks signatures only between the objects in your input. There is no trust store and no revocation check via OCSP or by downloading a CRL.
No network access to servers: it opens no TLS connection and doesn't fetch server certificates — that's what the SSL checker is for, which hands the chain over at the click of a button.
Signatures that can't be checked: MD5, SHA-224, Ed448, DSA, and the brainpool and secp256k1 curves are unknown to the Web Crypto API; such signatures stay "not checked". Ed25519 is only verified by browsers that support it.
No decryption: password-protected private keys and encrypted S/MIME messages are not opened; only PKCS#12 passwords are supported.
File size: up to 50 MB per file. PEM text and bare Base64 are only detected within the first 4 MB of a file, so in practice the 50 MB limit applies to binary (DER/BER) files. Save a larger Base64 .p7m as binary first, e.g. with base64 -d invoice.p7m > invoice-der.p7m.

For the introduction and target audiences see the overview page. Concrete walkthroughs are in the examples, strategy and pitfalls in the tips & tricks. You can try everything directly in the tool.