Default Java Keystore Password

Java applications protect cryptographic keys and certificates in a keystore, and every keystore is guarded by a password. The default Java keystore password shipped with the JDK’s trust store is changeit. Because that value is publicly documented, it is not suitable for any keystore that needs real protection.

This tutorial explains what a Java keystore is, shows how to change its password with the keytool command-line utility, and walks through verifying that the new password works.

What Is a Java Keystore?

A Java keystore is a file that stores cryptographic material: private keys with their certificate chains, and trusted public certificates. Java keystores come in several formats — JKS and PKCS12 are the most common — and keytool, which ships with the Java Development Kit (JDK), reads and writes them.

The JDK bundles a trust store named cacerts that holds the certificate authorities Java trusts by default. Its location depends on your Java installation: JDK 8 keeps it under jre/lib/security, while newer JDKs place it under lib/security inside JAVA_HOME. Keystores created for a specific application can live anywhere on disk, so always confirm which file an application actually loads before changing its password.

What Is the Default Java Keystore Password?

The default password for the JDK’s cacerts trust store is changeit. It is a well-known convention, which is precisely why it is a poor defense: anyone familiar with Java can open or modify a keystore that still uses it.

Keep in mind that changeit applies to the bundled cacerts file. A keystore created by you or your organization has whatever password was chosen at creation, and there is no recovery mechanism for a forgotten custom password — store it somewhere safe.

Change the Keystore Password with keytool

Change a keystore’s password with keytool -storepasswd. For a real keystore, run the command interactively — keytool -storepasswd -keystore /path/to/keystore.jks, replacing /path/to/keystore.jks with the actual file — so the secrets are typed at prompts instead of appearing in shell history. keytool first prompts Enter keystore password: for the current password (changeit on an unmodified cacerts file), then asks for the new password twice with New keystore password: and Re-enter new password:.

A few details matter:

• Point -keystore at the exact file the application loads; do not assume a fixed JAVA_HOME/jre/lib/security/cacerts path, since layouts vary between JDK versions and distributions.
• The -storepass and -new options accept the current and new passwords as command arguments for non-interactive use. That exposes them in shell history and process lists, so use them only on throwaway files or in secured automation.
• The interactive form pauses for typed input, so the script below performs the same -storepasswd operation unattended on a disposable file built from a throwaway self-signed certificate.

Run this example:

set -e
TMP="$(mktemp -d)"
cat > "$TMP/demo.crt" <<'PEM'
-----BEGIN CERTIFICATE-----
MIIC/zCCAeegAwIBAgIUa9tUIt8iYx/aaMtcdywj4SboyakwDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEZGVtbzAeFw0yNjEwMzAxMjIyMjRaFw0zNjEwMjcxMjIy
MjRaMA8xDTALBgNVBAMMBGRlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCsMo66EXV3Ic75iT7RamlTZYn3RkhqEAKYHNLDe1pIf4ovN0tDhoP1Ce99
BtP6UNLds86BLB9S9n+LHwOsdu5NxerqXGLY3+6n3LpQRy+nH1iCO+j+W51xhqN7
JCpu7ckwCGd1lWcFFInIRhQ7oNsobbTI5NB+k84Kh+U5cyr5eYVCvbvROi/l5P0J
wyaggYOKn8l+33kmBOopXso2I7FRcSXLNYQkQBw/oCjikpdWR/RwtwLZuxssOP3Y
GsFZYVqPjkDt2WcUSuM+CoFFNudQXkI4V3OQTe4P5tFNATOV+uwmHFIKvcaEv9W5
/SckhD979tYNikl/9TzSmeqP8XdNAgMBAAGjUzBRMB0GA1UdDgQWBBQBwJRi578D
+rJwBEsFH2kk4q42/zAfBgNVHSMEGDAWgBQBwJRi578D+rJwBEsFH2kk4q42/zAP
BgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBspuqrqHp3p4TKiuZm
Rh0xsR2PTjP/IycwWwNXK0F7zUgvEIw49o3QSgaOBz1x+DDGYQ0mjUZo6WlJ2A6z
vaYp13E7y40maTxccMS3UEzkJx7A0p9JkbrK+HwBLHN85YUwn/A1BW197+9eJpET
ilivdUYGUfBzcNS4dwk8YjDCJmycy/5KqN8xp4jFX9NN0aHT28SkmYzMrXJS/6qV
bdS6KoKbZJ+4BGPSS4G2JthX8oD85Ve/6AquFX25FpIomUgW7u9f3TQXsgS/Y3mx
bnDIVFsuA+E23baxwOq+LfBUcGSWbtwnt+ftarRmebfiE/3GZQ7aim7xHgKQxtYe
7YVQ
-----END CERTIFICATE-----
PEM
keytool -importcert -alias demo -file "$TMP/demo.crt" \
  -storetype JKS -keystore "$TMP/demo.jks" \
  -storepass changeit -noprompt > /dev/null 2>&1
keytool -storepasswd -keystore "$TMP/demo.jks" -storetype JKS \
  -storepass changeit -new newStorePass1 2>/dev/null
echo "keystore password changed"

keystore password changed

The script imports the throwaway certificate into a fresh JKS keystore whose starting password is changeit — mirroring the real default — then updates the store password to newStorePass1 without prompts. Importing a certificate keeps the demo fast and prompt-free; on your own keystore, prefer the interactive prompts described above.

Verify the New Keystore Password

Verify the change by listing the keystore’s contents with the new password: keytool -list -keystore /path/to/keystore.jks prompts Enter keystore password: and prints the keystore type and its entries when the password is correct. The non-interactive form passes the password with -storepass.

Run this example:

set -e
TMP="$(mktemp -d)"
cat > "$TMP/demo.crt" <<'PEM'
-----BEGIN CERTIFICATE-----
MIIC/zCCAeegAwIBAgIUa9tUIt8iYx/aaMtcdywj4SboyakwDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEZGVtbzAeFw0yNjEwMzAxMjIyMjRaFw0zNjEwMjcxMjIy
MjRaMA8xDTALBgNVBAMMBGRlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCsMo66EXV3Ic75iT7RamlTZYn3RkhqEAKYHNLDe1pIf4ovN0tDhoP1Ce99
BtP6UNLds86BLB9S9n+LHwOsdu5NxerqXGLY3+6n3LpQRy+nH1iCO+j+W51xhqN7
JCpu7ckwCGd1lWcFFInIRhQ7oNsobbTI5NB+k84Kh+U5cyr5eYVCvbvROi/l5P0J
wyaggYOKn8l+33kmBOopXso2I7FRcSXLNYQkQBw/oCjikpdWR/RwtwLZuxssOP3Y
GsFZYVqPjkDt2WcUSuM+CoFFNudQXkI4V3OQTe4P5tFNATOV+uwmHFIKvcaEv9W5
/SckhD979tYNikl/9TzSmeqP8XdNAgMBAAGjUzBRMB0GA1UdDgQWBBQBwJRi578D
+rJwBEsFH2kk4q42/zAfBgNVHSMEGDAWgBQBwJRi578D+rJwBEsFH2kk4q42/zAP
BgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBspuqrqHp3p4TKiuZm
Rh0xsR2PTjP/IycwWwNXK0F7zUgvEIw49o3QSgaOBz1x+DDGYQ0mjUZo6WlJ2A6z
vaYp13E7y40maTxccMS3UEzkJx7A0p9JkbrK+HwBLHN85YUwn/A1BW197+9eJpET
ilivdUYGUfBzcNS4dwk8YjDCJmycy/5KqN8xp4jFX9NN0aHT28SkmYzMrXJS/6qV
bdS6KoKbZJ+4BGPSS4G2JthX8oD85Ve/6AquFX25FpIomUgW7u9f3TQXsgS/Y3mx
bnDIVFsuA+E23baxwOq+LfBUcGSWbtwnt+ftarRmebfiE/3GZQ7aim7xHgKQxtYe
7YVQ
-----END CERTIFICATE-----
PEM
keytool -importcert -alias demo -file "$TMP/demo.crt" \
  -storetype JKS -keystore "$TMP/demo.jks" \
  -storepass changeit -noprompt > /dev/null 2>&1
keytool -storepasswd -keystore "$TMP/demo.jks" -storetype JKS \
  -storepass changeit -new newStorePass1 2>/dev/null
keytool -list -keystore "$TMP/demo.jks" -storetype JKS \
  -storepass newStorePass1 > "$TMP/demo.list" 2>/dev/null
grep "keystore contains" "$TMP/demo.list"

Your keystore contains 1 entry

The grep prints the entry-count line from the real listing. A successful listing proves the new password opens that specific file — had keytool rejected it, the command would have failed instead. It does not prove the keystore’s contents are what you expect or that the application using it is configured correctly; treat it as an access check, not a security audit.

Important Limitations and Security Practices

Changing the keystore password is one part of protecting a keystore. Keep these points in mind:

• Use a unique, hard-to-guess secret. A generated value or long passphrase is better than a pattern reused elsewhere. keytool accepts short passwords with only a warning, so meeting its minimum is not a security target.
• The keystore password is not the key password. -storepasswd changes only the password that opens the store. Private-key entries have their own passwords managed with -keypasswd, and some tools assume the two match while others treat them as distinct — check your tooling before changing one without the other.
• Protect the file, not just the password. Keep backups of the keystore in a secure location, restrict filesystem permissions so only accounts that need it can read it, and limit who can run keytool against it.
• Rotate when there is a reason. Change the password after suspected exposure or personnel changes; rotating on a fixed schedule is not automatically beneficial.

A changed password alone does not secure an application — combine it with protected backups, tight access, and proper storage of the secret itself.