PKCS#12 Keystore Inspector
Reads a PKCS#12 keystore the way `openssl pkcs12 -info` does, straight out of the bytes and entirely inside your browser. Half the file is readable with no password at all, and that half is shown first: the PFX version, the MAC digest with its iteration count and salt length, and one row per content block saying whether it is plaintext or encrypted and with which algorithm — PBES2 with AES-256-CBC and PBKDF2-HMAC-SHA256 for anything OpenSSL 3 wrote, pbeWithSHA1And40BitRC2-CBC for the files that make Java 21 and modern OpenSSL refuse to load a keystore at all. That answer alone is often the whole question. Enter the password and the tool verifies the MAC — computed with the PKCS#12 key derivation of RFC 7292 Appendix B, which is not PBKDF2 and is the detail most reimplementations get wrong — then decrypts the bags: every certificate with its subject, issuer, serial, validity window, subject alternative names, key algorithm and SHA-256 fingerprint, ordered leaf first through the chain, along with each bag's friendlyName and localKeyID, the alias your keytool or IIS import will use. It then answers the question a keystore is usually opened for: is a private key in here, and is it the leaf certificate's key? The public half is recovered from the key itself and compared byte for byte with the certificate's SubjectPublicKeyInfo, so the verdict is not a guess from a matching alias. What it cannot do is decrypt a legacy file: WebCrypto has no RC2, RC4, DES or Triple DES, so those keystores are named as legacy rather than half-parsed — although their MAC still verifies, so it will tell you whether your password is right even when it cannot open the bags. It also does not check the chain against any trust store, so a chain that ends in an unknown root looks exactly like one that does not.
How to use
- Drop the .p12 or .pfx on the box. The structure appears immediately — no password is needed to see the MAC algorithm, the iteration counts and the cipher guarding each block.
- Read the block table first if you are debugging an import failure. A row saying pbeWithSHA1And40BitRC2-CBC or 3-KeyTripleDES is a legacy keystore, and that is what Java 21, OpenSSL 3 and Windows are refusing.
- Type the password and press Unlock. The MAC line tells you at once whether the password is right and whether the file has been altered since it was written.
- Check the "Key and certificate" chip. It compares the public key recovered from the private key with the leaf certificate's own, which is the real test of whether this keystore can serve TLS.
- Read the certificates in order: the leaf is first, then each issuer above it. A missing intermediate here is exactly what makes a server work in a browser you have visited before and fail everywhere else.
Frequently asked questions
- Why can I see the algorithms and the MAC before I type the password?
- Because none of that is encrypted. A PFX is a version number, an authenticated safe and a MacData block; the safe is a list of content blocks, each either plaintext SafeContents or a PKCS#7 EncryptedData whose AlgorithmIdentifier names the cipher, the salt and the iteration count in the clear. Only the bag payloads inside are protected. That is why an inspector can tell you a file is a legacy RC2 keystore, how weak its iteration count is, and how many blocks it holds without knowing the password — and why you should never treat a .p12 as opaque just because it is password-protected.
- The tool says my keystore uses legacy algorithms. What do I actually do about it?
- Convert it once with OpenSSL: `openssl pkcs12 -legacy -in old.p12 -nodes -out tmp.pem -passin pass:…` and then `openssl pkcs12 -export -in tmp.pem -out new.p12`, which writes PBES2 with AES-256-CBC and PBKDF2-HMAC-SHA256 by default in OpenSSL 3. Delete tmp.pem afterwards; it holds the private key unencrypted. The -legacy flag exists because OpenSSL 3 moved RC2, RC4 and single DES into the legacy provider, and Java removed the same algorithms from its default keystore handling — a file written by a 2015 appliance is not corrupt, it is simply encrypted with primitives nothing enables any more.
- What is the difference between the MAC password and the encryption password?
- In principle they are two different passwords: RFC 7292 lets the integrity MAC and the privacy encryption use separate ones, and a few enterprise tools do exactly that. In practice every common exporter uses the same string for both, which is why a failed MAC is nearly always a wrong password rather than a tampered file. The two also derive their keys differently — the MAC key comes from the PKCS#12 derivation in Appendix B with ID 3, and modern bag encryption uses PBKDF2 over the password bytes — so a keystore can verify its MAC and still fail to decrypt if it really was written with two passwords.
- My .p12 opens but has no private key. Where did it go?
- It was probably never exported. `openssl pkcs12 -export -nokeys` and most "export certificate chain" buttons in a browser or an MMC console write a certificates-only keystore, which is a perfectly valid PFX with only certBags inside. This is the file people discover at the worst moment, because a web server or a load balancer will import it without complaint and then fail the TLS handshake with a key-mismatch error. The bag list here shows exactly which bags exist, so a keystore with no key bag is visible before you deploy it.
- What does the local key ID actually do?
- localKeyID is the attribute that pairs a certificate bag with a key bag, since a keystore may hold several of each. OpenSSL sets it to the SHA-1 hash of the certificate's public key, Windows and Java use their own values, and nothing in the format requires any particular scheme. friendlyName is the human alias — what keytool lists and what Windows shows in the certificate store — and importing a keystore whose friendlyName collides with an existing alias is a common source of "alias already exists" errors. Both are shown per bag here, along with which block each bag came from.
- Is it safe to open a keystore holding a private key in a web page?
- This page never sends the file or the password anywhere: parsing, the MAC check, PBKDF2, AES-CBC decryption and the key-to-certificate comparison all run in your tab through WebCrypto, and the password lives in component state that is discarded when you close it. Nothing is written to localStorage but the file name. That said, the genuinely safe habit with a production keystore is to check it with an offline `openssl pkcs12 -info`; use this for the keystores you are debugging, and treat any web tool that asks you to upload a .p12 with the suspicion it deserves.
Related tools
CSR Decoder (PKCS#10)
Read a certificate signing request before you send it: subject, SANs, key size, signature algorithm, and whether its self-signature verifies.
JSON Schema Validator
Check a JSON document against a JSON Schema in your browser. Every error gets its JSON Pointer, the line it lands on, and the keyword that failed.
CRL Decoder (X.509)
Read a certificate revocation list in your browser: issuer, CRL number, validity window, every revoked serial with its reason, and the signature.
Random IP & MAC Generator
Generate batches of random IPv4, IPv6, or MAC addresses for tests and mocks — public / private / ULA / link-local / UAA / LAA scopes supported.
Bcrypt Hash & Verify
Generate bcrypt hashes with adjustable cost factor, or verify an existing hash against a password — runs entirely in your browser.
PGP Public Key Inspector
Read an armored OpenPGP public key: full fingerprint, key ID, algorithm, size, creation and expiry dates, user IDs and subkeys.