Fix Java keytool Keystore Was Tampered With or Password Was Incorrect

You already hit the error — in a keytool command, a Tomcat log, or a Spring Boot stack trace: Keystore was tampered with, or password was incorrect (or the shorter PKCS12 variant, keystore password was incorrect). The wording sounds like a security incident, but on Linux it almost always means Java could not open the keystore with the password, path, or format in play.

Use the table below to jump to the cause that fits your situation. Each section explains why it happens and what to change. For keystore basics, see Java keystore vs truststore and the keytool cheatsheet.

Tested on: Ubuntu 26.04 LTS; OpenJDK 25.0.3; kernel 7.0.0-27-generic.

Prerequisites

• OpenJDK with keytool — Install keytool on Ubuntu.
• openssl for PKCS12 inspection and PEM conversion (OpenSSL).

What the error actually means

When keytool or the JVM loads a keystore, it decrypts PKCS12 data or verifies a JKS integrity MAC using the store password. If that check fails, OpenJDK throws a generic I/O error. The message is misleading — it rarely indicates real tampering.

On OpenJDK 25, JKS problems often print:

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

PKCS12 problems usually print:

keytool error: java.io.IOException: keystore password was incorrect

Treat both as the same class of problem: the store password did not unlock this file with this format.

Find your cause

Wrong store password

This is the most common cause. The keystore file is fine, but the password in your command or application config does not match the one used when the file was created.

You see it when:

• keytool -list -keystore server.jks -storepass <app-password> fails while ops insists the app password is correct
• Tomcat logs the tampered message on startup because certificateKeystorePassword (or legacy keystorePass) in server.xml drifted from the real store password
• An environment variable maps incorrectly to Spring's server.ssl.key-store-password — verify the resolved property, not only the env var name

Confirm with keytool using the password you believe is correct:

keytool -list -v -keystore /path/to/keystore -storepass 'PASSWORD'

On a JKS file with the wrong password, OpenJDK 25 reports:

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

When you have the right password, listing succeeds:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

testkey, Jul 3, 2026, PrivateKeyEntry,

Fix by aligning every layer to the same store password:

If you know the current password and need to rotate it:

keytool -storepasswd -keystore /path/to/keystore -storepass OLD -new NEW -noprompt

Update the application config before restart. For alias-level passwords, see Change alias, password, and delete entries.

Wrong keystore file at the path

Java is opening a file that is not a valid keystore, or not the keystore you think it is.

Typical situations:

• javax.net.ssl.keyStore points at cert.pem or fullchain.pem instead of a PKCS12/JKS container
• A stray ~/.keystore or upload-keystore.jks sits in the working directory and keytool picks it up when no -keystore path is given
• The path in config was updated but still references an old file from a previous deployment

Check what is actually on disk:

ls -la /path/to/keystore
file /path/to/keystore

A text placeholder produces a format error, not always the tampered message:

keytool error: java.security.KeyStoreException: Unrecognized keystore format. Please load it with a specified type

A real JKS file is reported as:

/path/to/keystore.jks: Java KeyStore

Fix by pointing config at the correct binary keystore. Convert PEM material with Import PEM private key into Java keystore or build PKCS12 with create PKCS12 from CRT and KEY. Remove or rename ghost keystores in the default location before regenerating.

JKS vs PKCS12 format mismatch

Since Java 9, new keystores default to PKCS12 (keystore.type=pkcs12 in $JAVA_HOME/conf/security/java.security). A file named .jks may still be PKCS12 if it was created on a modern JDK without -storetype JKS.

The mismatch shows up when:

• The app sets keystoreType="JKS" in Tomcat but the file is PKCS12
• Spring Boot omits server.ssl.key-store-type and assumes PKCS12 while the file is legacy JKS
• keytool -list succeeds without -storetype (OpenJDK auto-detects) but the JVM fails because the app hard-codes the wrong type

Probe with explicit types:

keytool -list -keystore /path/to/keystore -storetype JKS     -storepass 'PASSWORD'
keytool -list -keystore /path/to/keystore -storetype PKCS12 -storepass 'PASSWORD'

Whichever command lists entries is the format to set in the app:

• Tomcat: keystoreType="PKCS12" or keystoreType="JKS"
• Spring Boot: server.ssl.key-store-type=PKCS12
• JVM: -Djavax.net.ssl.keyStoreType=PKCS12

Prefer PKCS12 for new keystores. Convert legacy JKS with Convert JKS to PKCS12.

Store password vs key password in the app

For JKS keystores, the store password (unlocks the file) and the key password (unlocks an individual private-key entry) can differ. In Java/keytool workflows, PKCS12 is normally configured with the same store and key password.

You are in this situation when:

• keytool -list -keystore store.jks -storepass correct works
• Tomcat or a custom SSL setup still fails because certificateKeyPassword (or legacy keyPass) does not match the entry password from keytool -genkeypair -keypass

Align both values in config:

For PKCS12, set store and key passwords to the same value in both keytool and the application.

Wrong password on Ubuntu cacerts

The system truststore on Ubuntu is a symlink:

ls -l /etc/ssl/certs/java/cacerts

The default store password is changeit. A wrong password gives:

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

With the default:

keytool -list -cacerts -storepass changeit | head -6

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 121 entries

debian:ac_raiz_fnmt-rcm.pem, Jul 2, 2026, trustedCertEntry,

If ca-certificates-java upgrades fail because someone changed the cacerts password or corrupted the file, and you have no custom CA entries to keep:

sudo cp /etc/ssl/certs/java/cacerts /root/cacerts.backup.$(date +%F)
sudo rm /etc/ssl/certs/java/cacerts
sudo update-ca-certificates -f

Re-import custom corporate roots afterward — see Import certificate into Java cacerts on Linux.

Wrong source password on importkeystore

When converting PEM or PKCS12 material to JKS — common after Let's Encrypt on Ubuntu — the error often appears on keytool -importkeystore even though the destination password is fine.

The usual mistake is mixing up passwords:

• -srcstorepass must match the password passed to openssl pkcs12 -export (or the source PKCS12 file's password)
• -deststorepass and -destkeypass are for the new JKS file and must be at least six characters

Wrong source password:

Importing keystore keystore.p12 to eap.jks...
keytool error: java.io.IOException: keystore password was incorrect

Correct import when openssl pkcs12 -export ... -password pass:myeapc created the source:

keytool -importkeystore \
  -srckeystore keystore.p12 -srcstoretype PKCS12 -srcstorepass myeapc \
  -destkeystore eap.jks -deststoretype JKS \
  -deststorepass tplink8xx -destkeypass tplink8xx

Importing keystore keystore.p12 to eap.jks...
Entry for alias eap successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

If passwords are correct but import still fails, inspect the PKCS12 with openssl pkcs12 -info — malformed certificates (for example an empty issuer DN) can surface as a misleading password error. More patterns in Import PKCS12/PFX into Java keystore.

Corrupted or incomplete keystore file

A truncated copy or a crash during keystore write leaves bytes that no password can open. You may see:

keytool error: java.io.EOFException

instead of the tampered message. This also happens after partial scp command, failed cert renewal scripts that overwrite the keystore mid-write, or server crashes during an installer upgrade.

If keytool -list fails with every password you try and file reports Java KeyStore or binary data, treat the file as damaged. Restore from backup or rebuild from original PEM/PKCS12 sources — there is no repair command.

Recreate when the password is lost

Java keystores cannot be decrypted without the store password. If no password works and you have no backup of the PKCS12/JKS file, recovery is not possible.

Rebuild from material you still hold:

• cert.pem + privkey.pem → openssl pkcs12 -export → import with keytool
• PKCS12/PFX backup from the certificate issuer
• New keytool -genkeypair and a fresh CSR to your CA

For stock cacerts with no custom entries, delete and regenerate as described in Wrong password on Ubuntu cacerts.

Quick lab reproduction

To reproduce the JKS variant safely, create a test keystore and list it with the wrong password:

keytool -genkeypair -alias testkey -keyalg RSA -keystore test.jks \
  -storetype JKS -storepass secretpass -keypass secretpass \
  -dname "CN=test" -noprompt

keytool -list -keystore test.jks -storepass wrongpass

keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect

Run this only in a throwaway directory — not against production keystores.

Distinguish from other keytool errors

If the message is not a password or format problem at keystore open time, use a different guide:

References

• keytool documentation (Oracle)
• Java KeyStore API
• JEP 229: PKCS12 keystores by default

Summary

Start with the cause table: wrong store password, wrong file path, JKS/PKCS12 mismatch, store vs key password in the app, cacerts defaults, importkeystore source password, corruption, or a lost password each has its own section. The tampered wording is Java's way of saying the keystore did not open — align password, path, and format before assuming the file was attacked.