LiveChat 
Support 
Keytool List Certificates: How to View and Manage a Java Keystore
If you run Java applications that talk to other systems over HTTPS, sooner or later you will need to look inside a keystore. Whether you are debugging a `PKIX path building failed` error, rotating a TLS certificate, or simply confirming which Certificate Authorities your JVM trusts, the answer almost always starts with one command: keytool list certificates.
This guide explains what `keytool` and a keystore are, how to list and read certificate entries, how to inspect the JVM’s default `cacerts` truststore, and how to import, export, and delete entries. The examples are platform-neutral and work the same on Linux, macOS, and Windows wherever a JDK is installed.
Key Takeaways
• `keytool` is the certificate-management command bundled with every JDK; it reads and writes Java keystores.
• The core command is `keytool -list -keystore keystore.jks`; add `-v` for full details or `-alias` for a single entry.
• The JVM’s trusted CAs live in the `cacerts` truststore at `$JAVA_HOME/lib/security/cacerts`, default password `changeit`.
• PKCS12 is now the default, portable keystore format; JKS is the older Java-only format.
• Most Java SSL trust errors are fixed by importing the missing CA into the truststore with `keytool -importcert`.
What Is keytool and What Is a Java Keystore?
`keytool` is a key and certificate management utility shipped with the Java Development Kit (JDK). It lives alongside `java` and `javac` in the JDK’s `bin` directory, so if you can run Java, you already have `keytool`. It lets you create key pairs, generate certificate signing requests, and—most relevant here—list, import, export, and delete certificates.
A keystore is an encrypted file that stores cryptographic material: private keys with their certificate chains, and standalone trusted certificates. Each item is stored under a unique label called an alias.
There are two keystore formats you will encounter most often:
- JKS (Java KeyStore) — the legacy, Java-proprietary format. It still works but is no longer the default.
- PKCS12 (`.p12` / `.pfx`) — an industry-standard, cross-platform format. Since JDK 9, PKCS12 is the default keystore type, because it interoperates cleanly with tools like OpenSSL and modern web servers.
A related concept is the truststore: a keystore used specifically to hold the certificates of CAs you trust. The JVM ships with one built in, called `cacerts`.
How Do You List Certificates in a Keystore?
The fundamental command is straightforward:
“`bash keytool -list -keystore keystore.jks “`
You will be prompted for the keystore password. To supply it non-interactively (useful in scripts), add `-storepass`:
“`bash keytool -list -keystore keystore.jks -storepass changeit “`
The default output is compact—one line per alias showing the entry type, creation date, and the certificate’s SHA-256 fingerprint:
“` Keystore type: PKCS12 Keystore provider: SUN
Your keystore contains 2 entries
server, Jun 20, 2026, PrivateKeyEntry, Certificate fingerprint (SHA-256): A1:B2:C3:…:9F rootca, Jun 20, 2026, trustedCertEntry, Certificate fingerprint (SHA-256): D4:E5:F6:…:1A “`
Listing a Single Entry by Alias
When a keystore holds dozens of entries, narrow the output to one alias with `-alias`:
“`bash keytool -list -keystore keystore.jks -alias server -storepass changeit “`
Reading Full Certificate Details with -v
The compact view rarely tells you what you need. Add `-v` (verbose) to print the full record for each certificate—issuer, subject, validity dates, serial number, signature algorithm, and all fingerprint variants:
“`bash keytool -list -v -keystore keystore.jks -alias server -storepass changeit “`
The verbose output is where you confirm who issued a certificate, when it expires, and the MD5/SHA-1/SHA-256 fingerprints you use to match it against a known-good copy. For expiry triage, `Valid from … until …` in this output is the single most important line to read.
How Do You List the JVM’s Default Trusted CAs (cacerts)?
When a Java client makes an HTTPS connection, it decides whether to trust the server by checking the server’s certificate chain against its truststore. By default that truststore is `cacerts`, located at:
“` $JAVA_HOME/lib/security/cacerts “`
(On older JDK 8 layouts it may sit under `$JAVA_HOME/jre/lib/security/cacerts`.)
The default password for `cacerts` is the well-known string `changeit`. To list every CA your JVM trusts out of the box:
“`bash keytool -list -keystore “$JAVA_HOME/lib/security/cacerts” -storepass changeit “`
This prints the long roster of preinstalled root CAs. To check whether one specific authority is present, combine it with a search on the alias or pipe the output through your shell’s filter tool. Listing the truststore *first* is the diagnostic step most people skip—it instantly tells you whether a trust failure is caused by a genuinely missing CA or by something else entirely.
The single highest-leverage move in Java SSL debugging: the overwhelming majority of `PKIX path building failed` / `unable to find valid certification path` errors are not bugs in your code or your TLS configuration—they are simply a missing CA in the truststore. The fix is almost mechanical: list `cacerts` first to see what is already trusted, confirm the issuing CA is absent, then import it with `keytool -importcert`. Reaching for `-Dcom.sun.net.ssl.checkRevocation=false`, disabling certificate validation, or rewriting TLS settings before doing this is how a five-minute fix becomes a five-hour rabbit hole. List, confirm, import—in that order.
How Do You Import, Export, and Delete Certificates?
Beyond listing, `keytool` handles the full lifecycle of an entry.
Import a CA certificate into the truststore (the fix for most trust errors):
“`bash keytool -importcert -alias myca -file myca.crt \ -keystore “$JAVA_HOME/lib/security/cacerts” -storepass changeit “`
`keytool` shows the certificate details and asks `Trust this certificate? [no]:`—type `yes` to confirm. Always inspect the fingerprint it prints before trusting it.
Export a certificate from a keystore to a file (for example, to share a public certificate or back it up):
“`bash keytool -exportcert -alias server -file server.crt \ -keystore keystore.jks -storepass changeit “`
Add `-rfc` to export in the human-readable, Base64 PEM format instead of binary DER.
Delete an entry by alias:
“`bash keytool -delete -alias oldca -keystore keystore.jks -storepass changeit “`
Common keytool Commands at a Glance
| Task | Command |
|---|---|
| List all entries | `keytool -list -keystore keystore.jks` |
| List with full details | `keytool -list -v -keystore keystore.jks` |
| List one entry | `keytool -list -alias server -keystore keystore.jks` |
| List the JVM truststore | `keytool -list -keystore “$JAVA_HOME/lib/security/cacerts” -storepass changeit` |
| Import (trust) a CA cert | `keytool -importcert -alias myca -file myca.crt -keystore cacerts` |
| Export a certificate | `keytool -exportcert -alias server -file server.crt -keystore keystore.jks` |
| Export as PEM text | `keytool -exportcert -rfc -alias server -file server.pem -keystore keystore.jks` |
| Delete an entry | `keytool -delete -alias oldca -keystore keystore.jks` |
| Change a keystore password | `keytool -storepasswd -keystore keystore.jks` |
| Convert JKS to PKCS12 | `keytool -importkeystore -srckeystore old.jks -destkeystore new.p12 -deststoretype PKCS12` |
JKS vs PKCS12: Which Format Should You Use?
For new keystores, prefer PKCS12. It is the cross-platform standard, it is the default in modern JDKs, and it moves cleanly between Java, OpenSSL, web servers, and other ecosystems. JKS remains common only because of legacy systems created before the default changed.
If you have an old `.jks` file and want to modernize it, convert it rather than recreating it:
“`bash keytool -importkeystore -srckeystore keystore.jks \ -destkeystore keystore.p12 -deststoretype PKCS12 “`
`keytool` will list certificates from either format with the same `-list` syntax, so day-to-day inspection is identical regardless of which type you have.
When Should You Reach for keytool in Practice?
Three scenarios cover most real-world use:
- Debugging SSL/TLS trust failures. Your Java app throws `PKIX path building failed`. List `cacerts`, confirm the issuing CA is missing, and import it.
- Adding a private or internal CA. Corporate or self-managed CAs are not in the public `cacerts` roster by default. Import them so internal services are trusted.
- Auditing and rotation. Use `-list -v` to check expiry dates across your keystores so a certificate never lapses silently in production.
When your Java services depend on correctly configured keystores and truststores, you need an environment where you control the JVM and the filesystem. DarazHost VPS and dedicated server plans give you full root access, so you can install the exact JDK version you need, run `keytool` against system truststores, import internal CAs into `cacerts`, and manage certificates for your Java applications without restriction. With reliable infrastructure and 24/7 technical support, DarazHost is a solid foundation for Java workloads that depend on dependable SSL/TLS trust.
Frequently Asked Questions
What is the default password for the Java cacerts truststore? The default password is `changeit`. It is a well-known value, so on production systems you should change it with `keytool -storepasswd` and protect the file with appropriate filesystem permissions.
Where is the cacerts file located? On modern JDKs it is at `$JAVA_HOME/lib/security/cacerts`. On older JDK 8 installations it may be under `$JAVA_HOME/jre/lib/security/cacerts`. Run `keytool -list -keystore “$JAVA_HOME/lib/security/cacerts”` to confirm.
What is the difference between a keystore and a truststore? Technically both are keystore files in the same format. A keystore typically holds your own private keys and certificates (your identity), while a truststore holds the CA certificates you trust when validating others. The JVM’s `cacerts` file is a truststore.
How do I fix “PKIX path building failed” in Java? This almost always means the server’s issuing CA is not in your truststore. List `cacerts` to confirm it is missing, then import the CA certificate with `keytool -importcert -alias myca -file myca.crt -keystore cacerts -storepass changeit`.
Should I use JKS or PKCS12? Use PKCS12 for new keystores—it is the default in modern JDKs and is portable across tools and platforms. Convert legacy JKS files with `keytool -importkeystore -deststoretype PKCS12`.
