How to Inspect a JKS Keystore with keytool

Run keytool -list -v -storetype JKS -keystore app.jks to see which aliases a Java keystore contains. Check the entry type first. A TLS server or mTLS client identity needs a PrivateKeyEntry, while a truststore typically contains trustedCertEntry entries.

The PKIScope JKS Viewer can display JKS and JCEKS aliases, certificate expiry, fingerprints and chain length. To inspect a .pfx or .p12 file in the browser, use the PFX/P12 Viewer.

List aliases and inspect the configured identity

keytool -list -v -storetype JKS -keystore app.jks
keytool -list -v -storetype JKS -keystore app.jks -alias server

Run keytool from the same JDK release used by your application when checking compatibility. Supply the store password at the prompt so the tool can check integrity. Replace server with the alias configured in your application. For a PKCS#12 file, use -storetype PKCS12 and point -keystore at the correct file.

Alias name
Compare it with the runtime configuration. A keystore can contain multiple identities.
PrivateKeyEntry
Contains the private key and its certificate chain. The key may require a separate password. A listing alone cannot confirm that the runtime can unlock the key.
trustedCertEntry
Contains a trusted certificate. This is normal in a truststore. A server or mTLS client needs a private-key entry for its own identity.
Certificate chain length
For a CA-issued leaf, a length of 1 can indicate missing intermediates. For a self-signed identity, 1 is expected.

Export a public certificate from an alias

keytool -exportcert -rfc -storetype JKS -keystore app.jks \
  -alias server -file server.pem
openssl x509 -in server.pem -noout -subject -issuer -dates -sha256 -fingerprint

For a private-key alias, -exportcert exports the first certificate in the entry’s chain. To inspect every certificate in the stored chain, use the verbose listing. The certificate decoder can show the exported leaf’s SAN and other extensions.

Convert one JKS identity to PKCS#12

JDK 9 and later default to PKCS#12 when creating new keystores. Use -importkeystore to move an existing identity to a new file. The Bash example reads the new password without echoing it or putting it in command arguments. It uses the same password for the destination store and key for interoperability. Run it on a trusted machine and choose an unused destination filename.

(
  umask 077
  read -r -s -p 'New PKCS#12 password: ' PKISCOPE_DEST_PASSWORD
  printf '\n'
  export PKISCOPE_DEST_PASSWORD
  keytool -importkeystore \
    -srckeystore app.jks -srcstoretype JKS -srcalias server \
    -destkeystore app.p12 -deststoretype PKCS12 \
    -deststorepass:env PKISCOPE_DEST_PASSWORD \
    -destkeypass:env PKISCOPE_DEST_PASSWORD
)

Enter the source store password when prompted. If the source alias has its own key password, provide it when keytool asks. Verify the converted entry before changing application configuration.

keytool -list -v -storetype PKCS12 -keystore app.p12 -alias server

Compare the entry type, chain length and certificate fingerprints with the source listing. Update the application’s keystore type to PKCS12 and test the identity in the target runtime. For OpenSSL inspection of the resulting archive, see how to open a PFX or P12 file.

Diagnose common Java TLS failures

  • Alias does not exist. List all aliases and confirm the application is loading the expected file.
  • UnrecoverableKeyException. Check the private-key password for the configured alias separately from the store password.
  • PKIX path building failed. Check the peer’s presented chain and the truststore selected by the failing runtime. Use the certificate chain checker to look for missing intermediates.

Reference