Open your JKS & PKCS#12 keystores
Bare PEM files on disk are the exception. Java services, signing pipelines and load balancers keep their certificates in keystores — and a crypto inventory that skips them misses where production keys actually live.
pqlens scan keystore keystore.jks --password "$PQLENS_KEYSTORE_PASSWORD"
How it works
- Run
pqlens scan keystoreon a.jks,.p12or.pfxfile. - Supply the password with
--passwordor the$PQLENS_KEYSTORE_PASSWORDenvironment variable (better for shell history). - Every key and certificate inside is inventoried: algorithm, key size, signature hash, validity.
- Findings merge into the same inventory as your other surfaces.
The keystore password never leaves the process
The keystore is opened locally, in memory, exactly like keytool would — the password and the private keys inside are never written out, logged or transmitted. Prefer the environment variable over the flag so the password stays out of your shell history.
What tends to hide in old keystores
Keystores accumulate: the 2016 intermediate CA somebody imported to fix a handshake, self-signed certs from a proof-of-concept, and RSA-1024 keys that predate the current team. Because the container is opaque, none of it shows up in a filesystem certificate scan — which is why keystores are their own surface.
Frequently asked questions
Which keystore formats are supported?
PKCS#12 (.p12 and .pfx) and Java KeyStore (.jks).
Is the keystore password sent anywhere?
No. The keystore is opened locally and the password stays in process memory. Use $PQLENS_KEYSTORE_PASSWORD instead of --password to keep it out of shell history too.
Does PQLens extract or export the private keys?
No. It reads metadata — algorithms, key sizes, certificate details — to classify them. Key material is not written anywhere.