How to convert a Java keystore (JKS) to PKCS #12

Before you start

• A JDK with keytool. Use the newest JDK you have; the output below comes from OpenJDK 21.
• The JKS file and its store password, plus the key password for each private key entry if it differs from the store password. Look in the application’s configuration (for example a keyPass or key-password setting).
• A maintenance window if a running service uses the keystore: it reads the file at start-up.

JKS is a Java-only format. PKCS #12 is an open standard that OpenSSL, Windows and every current JDK read, and it has been Java’s default keystore type since JDK 9. keytool itself recommends the move every time it opens a JKS file.

Steps

1. Look at what is inside

keytool -list -keystore keystore.jks

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

keystone-root, Oct 20, 2026, trustedCertEntry, 
Certificate fingerprint (SHA-256): FE:F0:F5:E6:B9:C0:7B:2E:53:F6:D3:8B:0B:33:CD:0E:EA:81:C0:0D:B8:8D:50:38:88:0E:4E:D6:80:BE:5D:63
tomcat, Oct 20, 2026, PrivateKeyEntry, 
Certificate fingerprint (SHA-256): 69:E7:C4:BC:4E:AD:29:8A:05:5E:D3:C1:F9:FA:46:2A:2E:56:2C:7F:2D:93:C0:02:62:8E:0A:09:B5:72:D1:CA

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".

Note the aliases, the entry types and the fingerprints: you will compare them after the conversion. A PrivateKeyEntry is a key with its certificate chain; a trustedCertEntry is a CA certificate the application trusts.

2. Keep a copy

cp keystore.jks keystore.jks.bak

The copy holds private keys, so store it as carefully as the original, and delete it once the new file is in service.

3. Convert into a new file

keytool -importkeystore \
  -srckeystore keystore.jks -srcstoretype JKS \
  -destkeystore keystore.p12 -deststoretype PKCS12

keytool asks for the new store password (twice), then the source store password. If a key has its own password, it asks for that too:

Importing keystore keystore.jks to keystore.p12...
Entry for alias keystone-root successfully imported.
Enter key password for <tomcat>
Entry for alias tomcat successfully imported.
Import command completed:  2 entries successfully imported, 0 entries failed or cancelled

Three variants:

• One entry only: add -srcalias tomcat. Only with -srcalias can you also pass -srckeypass; without it keytool stops with if alias not specified, destalias and srckeypass must not be specified.
• From JCEKS, the other old Java format: use -srcstoretype JCEKS. Secret-key entries, such as an AES key an application uses to encrypt data, come across too: our test key showed up in the new file as a SecretKeyEntry.
• In place, as keytool suggests: keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12. The file keeps its name, becomes PKCS #12, and keytool reports The JKS keystore is backed up as "keystore.jks.old". A new file name is clearer, because a .jks file that holds PKCS #12 confuses the next person.

4. Understand the password change

A PKCS #12 keystore made by keytool uses one password for the store and every key in it. If you try to set a different key password, keytool says so:

Warning:  Different store and key passwords not supported for PKCS12 KeyStores. Ignoring user-specified -destkeypass value.

So if your application had a separate key password, set it to the new store password, or remove the setting if the application allows that.

5. Point the application at the new file

Change both the path and the type. For example:

• Tomcat: certificateKeystoreFile and certificateKeystoreType="PKCS12" in the Certificate element; see How to install a certificate in Tomcat and other Java servers.
• Spring Boot: server.ssl.key-store and server.ssl.key-store-type=PKCS12.
• JVM trust stores: -Djavax.net.ssl.trustStore=… with -Djavax.net.ssl.trustStoreType=PKCS12.

Restart the service, then test it from outside. If several applications share the keystore, switch them one at a time and keep the old file until the last one runs on the new file. Remember the copies: build pipelines, container images and configuration management often hold their own copy of the keystore and would bring the old one back at the next deployment.

Check it worked

List the new keystore and compare it with step 1:

keytool -list -keystore keystore.p12

Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 2 entries

keystone-root, Oct 20, 2026, trustedCertEntry, 
Certificate fingerprint (SHA-256): FE:F0:F5:E6:B9:C0:7B:2E:53:F6:D3:8B:0B:33:CD:0E:EA:81:C0:0D:B8:8D:50:38:88:0E:4E:D6:80:BE:5D:63
tomcat, Oct 20, 2026, PrivateKeyEntry, 
Certificate fingerprint (SHA-256): 69:E7:C4:BC:4E:AD:29:8A:05:5E:D3:C1:F9:FA:46:2A:2E:56:2C:7F:2D:93:C0:02:62:8E:0A:09:B5:72:D1:CA

Same aliases, same entry types, same fingerprints, and no warning. Because the file is now standard, OpenSSL reads it too:

openssl pkcs12 -in keystore.p12 -info -noout

MAC: sha256, Iteration 10000
MAC length: 32, salt length: 20
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Certificate bag
Certificate bag

From here you can extract PEM files for nginx or Apache with How to convert PFX (PKCS #12) to PEM. Trusted entries carry a Java-specific attribute that OpenSSL prints as Trusted key usage (Oracle); other tools ignore it.

Finally, check the running service with How to check the certificate chain a server sends.

If something goes wrong

• Enter key password for <tomcat> repeats, then Too many failures - try later: the key password differs from the store password and you gave the wrong one. Find it in the application’s configuration.
• Keystore was tampered with, or password was incorrect (JKS) or keystore password was incorrect (PKCS #12): the store password is wrong.
• if alias not specified, destalias and srckeypass must not be specified: add -srcalias, or leave out -srckeypass and answer the prompts.
• The application fails to start after the switch: check that the type setting says PKCS12 and that a separate key password setting now matches the store password (step 4).
• Clients or the application report PKIX path building failed: a converted trust store is missing entries, or the application still points at the old file. Compare the entry lists.
• An old Java runtime cannot open the new file: current JDKs protect PKCS #12 with AES-256 and a SHA-256 MAC, which OpenJDK-based Java 8 builds before update 342 (Oracle JDK 8 before 8u301) and Java 11 before 11.0.12 cannot read. Our Temurin 8u332 test said Integrity check failed: java.security.NoSuchAlgorithmException: Algorithm HmacPBESHA256 not available. Upgrade the runtime. If you cannot, create the file with keytool -J-Dkeystore.pkcs12.legacy -importkeystore …, which uses the old, weaker algorithms (40-bit RC2 and triple DES), and replace it once you can.

Why this works

keytool -importkeystore reads every entry with the source format’s rules and writes it again with the destination’s. The keys and certificates themselves do not change, which is why the fingerprints match. PKCS #12 (RFC 7292) stores the same things as JKS (keys with their chains, and trusted certificates) but in a documented, interoperable structure with modern password-based encryption. The file formats appendix compares JKS and PKCS #12, Who do we trust? explains trusted entries and cacerts, and Key pairs explains why the private key entries deserve the most care.

Go deeper

• Oracle: keytool (Java SE 21): -importkeystore and its options.
• JEP 229: Create PKCS12 keystores by default: why Java moved from JKS to PKCS #12.
• RFC 7292: the PKCS #12 format.
• Oracle: JSSE reference guide: the javax.net.ssl keystore and trust store properties.