# PKI Viewer — Tips & Tricks > Strategy and pitfalls for the PKI Viewer: matching fingerprints, watching expiry, what the viewer doesn't check, privacy, and tool combinations. Source: https://www.jpkc.com/db/en/tools/pki/tips/ Back to overview: [PKI Viewer](https://www.jpkc.com/db/en/tools/pki/) · Open the live tool: [www.jpkc.com/tools/pki/](https://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](https://www.jpkc.com/db/en/tools/pki/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)](https://www.jpkc.com/db/en/tools/cryptor/)** — when a shared password instead of asymmetric cryptography is enough to pass a text along confidentially. - **[Hash generator](https://www.jpkc.com/db/en/tools/hash/)** — compute checksums over certificate or key files to detect corruption or mix-ups. - **[Password & key generator](https://www.jpkc.com/db/en/tools/generator/)** — produce a strong password, e.g. for a new PKCS#12 container. --- The full function reference is in the [manual](https://www.jpkc.com/db/en/tools/pki/manual/), concrete walkthroughs in the [examples](https://www.jpkc.com/db/en/tools/pki/examples/). You can try everything in the [tool](https://www.jpkc.com/tools/pki/).