The Most Common Java Keytool Keystore Commands: A Complete Reference

Java Keytool is the JDK’s built-in certificate and key management utility. It manages keystores: container files that hold private keys, certificates, and trusted CA certificates, each identified by an alias. Understanding a small set of keytool commands covers the vast majority of day-to-day Java TLS administration tasks.

One thing to know before starting: since JDK 9, PKCS12 is the default keystore format and JKS (Java KeyStore) is deprecated. JKS is a proprietary Java format that cannot be used directly with OpenSSL or other TLS toolkits. If you are creating new keystores, create them as PKCS12. If you are maintaining old JKS keystores, plan to migrate. The commands in this reference work for both formats; differences are noted where they exist.

This reference is organized by task. Find the task you need, copy the command, and adjust the file names and aliases for your environment.

Keystore Fundamentals: JKS vs PKCS12, Keystores vs Truststores

The default trust store password is literally changeit. This is widely known and has been the default since Java’s earliest versions. Production Java deployments should change this, though in practice many do not. Changing it requires updating any tooling or configuration that references the cacerts file with the default password.

Inspecting Keystores and Certificates

Start here. Before making any changes to a keystore, list its contents to understand what is in it.

List all entries in a keystore

Print certificate details from a file (without importing)

The -sslserver flag is one of keytool’s most useful but underused features. It shows you exactly what certificate a live server is presenting, including the full SAN list, expiry date, and issuer chain. This is faster than OpenSSL s_client for a quick certificate check and requires no OpenSSL installation.

Creating a New Keystore and Key Pair

Create a new PKCS12 keystore with a key pair (modern approach)

Generate a CSR from an existing keystore entry

After creating a key pair, generate a Certificate Signing Request to send to a CA. The CA returns a signed certificate that you then import back into the keystore.

Importing Certificates and Private Keys

Import a CA-signed certificate (reply to CSR) into keystore

After the CA issues the certificate in response to your CSR, import it to associate it with the private key already in the keystore.

Keytool cannot import a private key directly from a PEM file. If you have a private key and certificate from an external source (generated with OpenSSL, downloaded from a CA, exported from another system), you must first create a PKCS12 file using OpenSSL, then import the PKCS12 into the keystore. The direct private key import workflow is covered in the next section.

Import a private key and certificate from an external source (via PKCS12)

This is the workflow for importing a key and certificate pair that was not generated by keytool: for example, a certificate and key pair from Let’s Encrypt, OpenSSL, or another system.

Add a trusted CA certificate to the JVM trust store

The most common reason for PKIX path building failed errors in Java is that the server’s CA certificate is not in the JVM’s cacerts trust store. Add it:

Exporting Certificates and Converting Formats

Export a certificate from a keystore to a file

Convert JKS keystore to PKCS12 (migration path)

In PKCS12, the key password and store password must be the same. JKS allows them to differ. If your JKS has different key and store passwords, you must specify -srckeypass during migration. After migration to PKCS12, only the store password matters for all operations.

Maintenance: Delete, Rename, and Password Operations

Delete a keystore entry

Rename an alias

Change keystore password

Common Errors and What They Mean

Quick Reference: Command Flags

Frequently Asked Questions

What is the difference between a keystore and a truststore?

A keystore holds private keys and the certificates associated with them. A Java application uses its keystore when it needs to present a certificate to another party, such as when acting as an HTTPS server or using mutual TLS as a client. A truststore holds trusted CA certificates. A Java application uses its truststore when it needs to validate a certificate presented by a remote server, checking whether the certificate chains to a trusted CA. In practice, the same keystore file can serve as both, with PrivateKeyEntry entries for keys and trustedCertEntry entries for trusted CAs. The JVM’s default truststore is the cacerts file in $JAVA_HOME/lib/security/.

Should I use JKS or PKCS12?

PKCS12. JKS is a proprietary Java format deprecated since JDK 9. PKCS12 is an industry standard that interoperates with OpenSSL, Windows Certificate Store, macOS Keychain, and all other TLS toolkits. If you need to convert a certificate from a Java keystore to use with Nginx or Apache, PKCS12 can be used directly with those tools. JKS cannot. Migrate existing JKS keystores to PKCS12 using the keytool -importkeystore command with -deststoretype PKCS12.

What does ‘PKIX path building failed’ mean and how do I fix it?

This is the most common Java TLS error. It means the JVM tried to validate the certificate presented by a server and could not trace it to any trusted CA in its trust store. The CA that signed the server’s certificate is not in the cacerts file. Fix it by importing the missing CA certificate into cacerts (keytool -importcert -alias caname -file ca.crt -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit -trustcacerts) or into a custom trust store that you pass to the JVM with -Djavax.net.ssl.trustStore.

How do I import a private key into a Java keystore?

Keytool cannot import a private key directly from a PEM file. The workflow is: use OpenSSL to create a PKCS12 file containing the private key and certificate (openssl pkcs12 -export -inkey private.key -in cert.pem -out bundle.p12), then import the PKCS12 into the Java keystore using keytool -importkeystore with -srcstoretype PKCS12. This two-step process is required for any private key that was not originally generated by keytool.

How do I check when a certificate in a keystore expires?

Run keytool -list -v -keystore keystore.p12 -storepass yourpassword and look for the Valid from and until lines in the output for each entry. For a specific alias: keytool -list -v -keystore keystore.p12 -storepass yourpassword -alias myserver. The valid until date shows the certificate expiry. To check a live server’s certificate expiry without accessing the keystore directly, use keytool -printcert -sslserver yourdomain.com:443 and look for the valid until field.

My Tomcat application is showing SSL errors after I updated the certificate. What should I check?

First verify the keystore contains the new certificate: keytool -list -v -keystore /path/to/keystore.p12 -storepass yourpassword. Confirm the alias in the keystore matches the alias configured in Tomcat’s server.xml (the keystoreAlias attribute in the Connector element). Confirm the keystore path and password in server.xml match the current file and password. Check that the entry type is PrivateKeyEntry, not trustedCertEntry, which would mean the certificate was imported without its private key. After verifying all of this, restart Tomcat and check the Tomcat log for SSL initialization errors on startup.