PKI Viewer — Tips & Tricks

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

The PKI Viewer is quick to operate — the value lies in reading the right fields and knowing the tool's limits. This page collects what matters in practice. The technical background is in the manual.

The viewer inspects; it doesn't judge

The most important framing first: the PKI Viewer reads certificates and verifies signatures between the objects you give it — but it makes no trust decision. A valid across a chain means: each certificate was signed by its issuer in your input — whether they are in the right order is a separate note. Whether the root is in a trust store, whether a certificate has been revoked, or whether a browser would accept the connection, it doesn't tell you. These are deliberate limits:

No trust store — a self-built chain with your own root is just as "valid" to the tool as a public one.
No OCSP or online CRL revocation check — a "Valid" badge in the card header only means "valid in time", not "not revoked". A CRL that you download yourself and add to the input is, however, matched against your certificates.
No server test — the tool doesn't connect to a host. For "does this certificate match the running server?", use the SSL checker and hand the chain over from there with the PKI Viewer button.

So use the viewer as a breakdown and consistency check of what's in the file — not as a trust verdict.

Fingerprints are the most reliable match

If you want to be sure that two certificates are identical, compare the SHA-256 fingerprint, not the common name or the serial number. The fingerprint depends on the entire certificate; even a single changed byte yields a completely different value. The copy button next to the fingerprint makes comparing it against the value from your browser or a monitoring system convenient. The tool also shows SHA-1, mainly for older systems — but rely on SHA-256 for comparisons.

When it's the key you care about, the public key pin (pin-sha256) is the right value: it stays the same when a certificate is renewed with the same key and changes as soon as a new key is involved. Compare the pin of a CSR with that of the issued certificate and you'll know immediately whether the CA really certified your key.

Keep an eye on expiry

The Not After field is colour-coded and shows the days remaining: a yellow Expires in N days appears once 30 days or fewer are left, red for Expired. That's a good quick test, but it's no substitute for monitoring — the viewer only checks what you give it right now. For production endpoints, expiry monitoring belongs in automation; the viewer is the tool for a quick manual look in between. With a chain, look at every card: an expiring intermediate takes the service down just as surely as an expiring server certificate.

Read self-signed and CA correctly

Two badges are easily confused:

Self-signed means: subject equals issuer, and the certificate's signature can be confirmed with its own key. That's normal for any root CA certificate, but on an end-entity certificate it's a sign that it doesn't come from a CA (e.g. a test or internal certificate). If the badge is missing even though the issuer is followed by "(same as subject)", the self-signature is invalid or couldn't be checked in the browser — the Signature row shows the result, with a reason where available.
CA means: Basic Constraints CA: Yes — the certificate is allowed to sign other certificates.

A root CA certificate typically carries both badges, an intermediate only CA, an ordinary server certificate neither.

Chain order: leaf first

Some servers and clients expect the chain in a fixed order: your own certificate first, then the intermediate that issued it, and so on. That's exactly what the note below the Certificate Chain card checks. If it says "Not in the usual order" in yellow, reorder the PEM blocks in your fullchain.pem. You usually don't need to send the root — the client already has it in its own trust store. A missing intermediate ("issued by … (not included)"), on the other hand, means a client can't follow the chain up to its root.

When opening sensitive files: lean on the privacy guarantee

Because the entire analysis runs in the browser — parser and signature checks included — it's safe to enter real private keys and PKCS#12 passwords here: nothing is uploaded. If you want to be completely sure, open the Network tab of your developer tools first: while analysing, you'll see no upload of your file; requests only go out when you load a sample file from the Example menu or explicitly click Load remote images in an email preview (the browser then fetches the images from the sender's server). With a wrong PKCS#12 password you can retry as often as you like without anything leaving your device.

Check certificate and key in one go

The most common slip during a certificate swap: the new key ends up next to the old certificate. So drop the certificate and private key into the PEM Decoder together — the Private Key card tells you under Matching Certificate right away whether they belong together, and the matching certificate gets the Private key included badge. That works for RSA, EC, and Ed25519 keys and in the PKCS#8, PKCS#1, and SEC1 formats. If the key is encrypted, the tool only shows its protection scheme; in that case decrypt it briefly on your machine with openssl pkey and delete the plain copy once you're done.

Pull individual certificates out of a chain

When you load a chain or a .ca-bundle, the tool renders each certificate separately — with Copy PEM and Download .crt on every card. That's the fast way to extract just the intermediate or just the root certificate from a bundle without splitting the blocks by hand. The list in the Certificate Chain card shows which certificate issued which; clicking a name jumps to its card.

P7M: content, signature and certificate belong together

With .p7m files you usually care about three things: the signed document, the validity of the signature, and the signing certificate. The tool shows all three in that order — the Signed content card (or E-mail message for S/MIME) with a download, the Signature card with the verification result, and the contained certificates below. Read the valid carefully: it confirms that the content is unchanged since signing and was signed with the key of the certificate shown. Whether you trust that certificate is your call — look at its card for that: issuer, validity, Extended Key Usage (emailProtection for S/MIME, documentSigning for document signatures). The Signing Time comes from the signer and is not an independent timestamp.

If all you have is a detached signature (a .p7s next to the actual file), load the .p7s first and then pick the original via Select the signed file to verify.

Load remote images in S/MIME mails deliberately

The HTML preview of a signed email blocks images from third-party servers. That's on purpose: a single loaded image — often an invisible tracking pixel — tells the sender that and when you opened the message, along with your IP address. Embedded images (cid:) still appear. If you really need the remote images, click Load remote images in the preview — but only once you trust the sender.

When a signature stays "not checked"

not checked isn't a flaw in the certificate; it means the tool couldn't verify, and the reason is right next to it. The most common causes:

Issuer missing — "Issuer certificate not included". Add the intermediate or root certificate to the input.
Signer certificate missing — "The signer's certificate is not included." For P7M files the tool looks for the signer's certificate only inside the container itself; pasting the certificate separately doesn't help here. That leaves the command line, e.g. openssl cms -verify.
Scheme not in Web Crypto — MD5, SHA-224, Ed448, DSA, and the brainpool and secp256k1 curves are unknown to the Web Crypto API. Only the command line helps here, e.g. openssl verify for certificates or openssl cms -verify for P7M files.
Ed25519 in the browser — older browsers don't support Ed25519 in Web Crypto yet; a current browser solves that.
No HTTPS connection — Web Crypto is only available in secure contexts. That applies to certificates, CSRs, and revocation lists; P7M signatures stay at "checking…" without HTTPS.

All other fields — subject, SANs, validity, fingerprints, key — are displayed correctly regardless.

Combining with other JPKCom tools

DNS, SSL, Redirect & URL — fetch a server's chain and hand it over for detailed analysis with the PKI Viewer button.
Cryptor (AES-256) — when a shared password instead of asymmetric cryptography is enough to pass a text along confidentially.
Hash Generator — compute checksums over certificate or key files to detect corruption or mix-ups.
Generator — produce a strong password, e.g. for a new PKCS#12 container.

The full function reference is in the manual, concrete walkthroughs in the examples. You can try everything in the tool.