Keystore formats

PKCS#12, JKS, and JCEKS: what each CertView plugin can inspect

Compare PKCS#12/PFX, JKS, and JCEKS support in CertView for VS Code and JetBrains, including password handling and validation boundaries.

By Juan Torchia · GMM Software Solutions7 min read

A filename extension is only a hint. The useful questions are which container format is present, which entry types it can hold, which runtime must consume it, and whether the inspection tool supports that exact combination.

PKCS#12 / PFX

PKCS#12 is a cross-platform container commonly used for private keys with certificate chains and for certificate-only bundles. Java uses PKCS12 as its default keystore type, and Oracle recommends it over JKS and JCEKS. Both CertView plugins can inspect supported PKCS#12/PFX inputs after a local password prompt.

JKS

JKS is a proprietary Java keystore format. It can contain trusted certificate entries and private-key entries protected by passwords. CertView for JetBrains supports JKS inspection because Java keystores are common beside JVM application and signing work. CertView for VS Code does not claim JKS support.

JCEKS

JCEKS is another proprietary Java format and historically offered stronger private-key protection than JKS, but it relies on legacy cryptography. Oracle's current Java security guidance says JKS and JCEKS will be removed in a future release and advises migration to PKCS12. CertView for JetBrains can inspect JCEKS; the VS Code extension does not claim it.

Capability matrix

  • CertView for VS Code: PKCS#12/PFX plus PEM, DER, certificates, chains, CSRs, CRLs, PKCS#7, keys, and JWK inputs.
  • CertView for JetBrains: PKCS#12/PFX, JKS, and JCEKS keystores plus PEM, DER, CRT, and CER certificates.
  • VS Code rejects files above 5 MiB before parsing; JetBrains limits certificate files to 1 MiB and keystores to 10 MiB.
  • Passwords remain in the local IDE flow. Neither plugin is a trust, revocation, WebPKI, or compliance decision engine.

Migration and production decisions

Inspection helps inventory aliases, entry types, subjects, issuers, validity windows, and chain contents before a migration. Conversion still needs a backed-up original, the correct key and store passwords, a controlled keytool or application workflow, and a test in the runtime that will consume the result.

keytool -list -v -keystore app.jks -storetype JKS
keytool -importkeystore -srckeystore app.jks -srcstoretype JKS -destkeystore app.p12 -deststoretype PKCS12

Do not paste real keystore passwords into scripts, issues, chat, or command history. Use your organization's secret-handling process and verify the converted store before switching production consumers.

Primary sources and implementation