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 but does not evaluate them in the sense of a trust decision. It does not tell you whether a certificate comes from a trusted CA, whether it has been revoked, or whether the chain leads cleanly up to a root. These are deliberate limits:

No chain validation against a trust store.
No OCSP/CRL revocation check — a displayed "Valid" only means "valid in time", not "not revoked".
No server test — the tool does not connect to a host. For "does this certificate match the running server?" you need openssl s_client or an online SSL checker.

So use the viewer as a breakdown 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.

Keep an eye on expiry

The Not After field is colour-coded: a yellow Expires in N days appears once fewer than 30 days remain, 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.

Read self-signed and CA correctly

Two badges are easily confused:

Self-signed means: subject equals issuer — the certificate signed itself. That's normal for any root CA certificate, but on an end-entity certificate it's a sign that it does not come from a CA (e.g. a test or internal certificate).
CA means: Basic Constraints CA: Yes — the certificate is allowed to sign other certificates.

A root CA certificate typically carries both badges; an ordinary server certificate neither.

When opening sensitive files: lean on the privacy guarantee

Because all analysis runs client-side via node-forge, 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. With a wrong PKCS#12 password you can retry as often as you like without anything leaving your device.

Pull individual certificates out of a chain

When you load a chain or a .ca-bundle, the tool renders each certificate separately — including Copy PEM per 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. Use the issuer/subject matching of the cards to understand the order of the chain.

P7M: content first, then certificates

With .p7m files you often care about both: the signed document and the signing certificate. The tool shows both — the Encapsulated Content card for the content (with download and, if it's a MIME email, header/attachment breakdown) and the contained certificates below. Note: the viewer extracts the signed content; it does not verify the signature cryptographically. For purely rescuing content from a signed email that's enough; for "is the signature valid?" you need an S/MIME-capable tool.

RSA now, EC only partially

Full key details (bit length, etc.) currently exist only for RSA. For EC certificates the tool does recognise the signature algorithm (ECDSA with SHA-256 …) but may show only Unknown type for the public key. Don't let that throw you — the rest of the certificate (subject, SANs, validity, fingerprints) is still displayed correctly.

Combining with other JPKCom tools

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.
Password & key 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.