JPKCom DB

PKI Viewer — Examples

PKI Viewer walkthroughs: check a certificate and chain, verify a P7M signature, open PKCS#12, cross-check a CSR, a key pair, and a revocation list.

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

This page shows the PKI Viewer through concrete walkthroughs. How the individual functions work in detail is covered in the manual.

Example 1: Quickly inspect a certificate

Goal: read off from a PEM block who a certificate is for and how long it's valid.

  1. In the PEM Decoder tab, paste the certificate text (-----BEGIN CERTIFICATE----- …) into the input field. If you don't have one handy, click Example — that loads a self-signed sample certificate for example.com.
  2. Give it a moment: the card appears as soon as you paste. You only need Decode if you want to trigger the evaluation again.

Result: a certificate card appears with subject, issuer, serial number, and the validity period including the remaining lifetime ("N days left"). In the card header, a badge tells you instantly whether the certificate is Valid, Expired, Not yet valid, or in how many days it expires. With the sample you also see Self-signed — subject and issuer are identical, and the Signature row confirms with valid (self-signed) that the certificate really did sign itself — and CA, because Basic Constraints marks it as a CA.

Example 2: Check a server certificate's remaining life and hostnames

Goal: before a deployment, verify which domains a certificate covers and whether it's about to expire.

  1. Load the server certificate as .pem/.crt via File Analyzer → Browse Files — or export it from your browser via the padlock icon and drop it in here.
  2. Look at the card.

Result: under Subject Alt Names the covered hostnames appear as badges (DNS:www.example.com, DNS:example.com …), plus any IP addresses as IP:…. The Not After field is colour-coded: if the header shows a yellow Expires in N days, it's time to kick off renewal. Under Extended Key Usage, serverAuth confirms it's intended as a TLS server certificate. To fetch the certificate straight from the running server, use the SSL checker — see example 8.

Example 3: Analyse a certificate chain

Goal: understand and verify a chain of end-entity, intermediate, and root certificates.

  1. In the File Analyzer, open the Example dropdown and choose ECDSA chain (leaf → intermediate → root). (Alternatively, paste your own chain — several -----BEGIN CERTIFICATE----- blocks in sequence.)

Result: the summary reports "Found 3 certificates.", followed by the Certificate Chain card: www.example.com — issued by #2 Example ECC CA E1, the intermediate — issued by #3 Example Root CA R1, the root — self-signed root, each with a valid badge. The green note "Order: leaf first, each certificate followed by its issuer." confirms the order servers should deliver. The cards show that the chain mixes key types: the leaf uses EC P-256 (prime256v1), the intermediate EC P-384 (secp384r1), the root RSA 3072 bit. The leaf also shows Authority Info Access (OCSP and CA issuer URL), CRL Distribution Points, the Domain Validated (DV) policy, and two IP addresses in the SAN alongside the DNS names. With Show PEM / Copy PEM / Download .crt you can pull out each certificate individually — handy for adding just the root to a trust store, for instance.

Example 4: Get the content out of a signed P7M file and verify the signature

Goal: reveal and download the document embedded in a .p7m file, and make sure it hasn't been changed since it was signed.

  1. In the File Analyzer, open the Example dropdown and choose Signed text document. (Or drop in your own .p7m file.)

Result: the tool recognises the PKCS#7 container and first shows the Signed content card: type "Text", size, the download name example-signed.txt, and a preview of the text. Download saves the document. Below it, the Signature card sums up who signed (Test Signing Certificate, linked to its certificate card), when according to the signer, with which scheme (SHA-256, RSA) — and under Status, valid with "content unchanged since signing". If even a single byte of the content had been changed, you'd see invalid there with a note that the message digest doesn't match.

If the embedded content is an email — try S/MIME e-mail: text + HTML + PDF — the tool shows the E-mail message card instead of Signed content, with the headers (From/To/Subject/Date/Message-ID), the text and HTML parts, and the attachments, which you can download individually; Original (.eml) saves the raw email. The signature card below works the same way.

Example 5: Open a PKCS#12 container

Goal: view a certificate and private key from a password-protected .p12/.pfx file.

  1. In the File Analyzer, drop in the .p12 or .pfx file or select it via Browse Files. To try it out, Example → PKCS#12 (password: example) opens a sample container and fills in the password for you.
  2. With your own file, the PKCS#12 Password row appears. Enter the container password and click Open (or press Enter).

Result: with the correct password the tool reports how many certificates and private keys it found — for the sample "Found 2 certificates, 1 private key." — and shows them as cards, including the display name (www.example.com). The key card states type (EC P-256 (prime256v1)) and format, and under Matching Certificate reports "matches #1 www.example.com"; the matching certificate carries the Private key included badge in return. With a wrong password you get "Wrong password." — everything stays local, so you can try as often as you like.

Example 6: Double-check a CSR before submitting

Goal: verify that a certificate signing request contains the right data before it goes to the CA.

  1. In the PEM Decoder, paste the CSR text (-----BEGIN CERTIFICATE REQUEST----- …).

Result: the Certificate Signing Request card shows the Subject (the requested DN fields such as CN, O, C), the type and size of the public key, and the signature algorithm. The Signature row should read valid — proof that the CSR was signed with the matching private key. If the CSR requests Subject Alternative Names or other extensions, they appear just as on a certificate, the SANs as DNS: badges. That way a typo in the common name or a forgotten domain stands out before the certificate is issued. You can later compare the CSR's Public Key Pin with that of the issued certificate: if they match, the same key is inside.

Example 7: Check whether certificate and private key belong together

Goal: before installing on a server, make sure cert.pem and key.pem are a pair.

  1. In the PEM Decoder, paste the certificate block first and the private key block (-----BEGIN PRIVATE KEY-----, RSA PRIVATE KEY, or EC PRIVATE KEY) directly below it — or drop a combined PEM file containing both into the File Analyzer.

Result: the Private Key card reports under Matching Certificate either "matches" with a link to the matching certificate — which then carries the Private key included badge — or "matches none of the certificates". In the second case you've got the wrong pair, such as the key from an earlier renewal. If the key is encrypted, the tool only shows the Encrypted Private Key card with the protection scheme; in that case decrypt it locally (openssl pkey), check the pair, and delete the plain copy again.

Example 8: Pull a server's chain in from the SSL checker

Goal: look in detail at the certificate chain a server actually delivers.

  1. In the SSL checker of the "DNS, SSL, Redirect & URL" tool, check the host.
  2. In the Certificate Chain card, click PKI Viewer.

Result: the PKI Viewer opens in a new tab, switches to the PEM Decoder, and shows the handed-over chain with the chain card, the order note, and a signature check for every link. That tells you at a glance whether the server forgets an intermediate ("issued by … (not included)") or sends the certificates in the wrong order.

Example 9: Check a certificate against a revocation list

Goal: find out whether a specific certificate is on its issuer's CRL.

  1. Download the CRL from the URL listed under CRL Distribution Points (the tool itself doesn't fetch anything).
  2. In the PEM Decoder, paste the certificate, the issuer certificate, and the CRL as PEM, one below the other. If you only have the CRL in binary (DER) form, convert it first:
openssl crl -inform DER -in issuer.crl -out issuer-crl.pem

Result: the Certificate Revocation List card shows the issuer, CRL number, This Update and Next Update, and the list's signature, verified against the issuer certificate you supplied. In the table of revoked serial numbers, a hit is highlighted in red and labelled with your certificate's name — then it's revoked, with date and reason alongside. No highlight means it isn't among the entries shown. The table shows at most 500 revocations; for a longer list, check the rest with openssl crl -in issuer-crl.pem -noout -text.

There's more on the individual functions in the manual, strategic advice and pitfalls in the tips & tricks. To get going right away, head to the tool.