What causes PKIX path building failed in Java?

The JVM could not build a trust chain from the server's certificate up to a root CA in its truststore. Usually the server is not sending its intermediate certificates, or the certificate is from a private/self-signed CA the JVM does not trust.

Should I import the certificate with keytool or fix the server?

Fix the server if it is failing to send intermediates, that one change fixes every client. Import into a truststore only when the certificate is from a legitimate internal or private CA, and import the CA, not the leaf.

Why does it still fail after I ran keytool?

Usually the wrong JVM: you imported into one JDK's cacerts but the app runs under another. Confirm which java is executing, or point the app at your truststore explicitly with -Djavax.net.ssl.trustStore.

How to Fix Java "PKIX path building failed"

VigilDog Team · October 21, 2026 · 7 min read

Few Java errors are as instantly recognizable, or as under-explained, as "PKIX path building failed." It means your JVM tried to verify a TLS certificate, could not build a chain from that certificate up to a root it trusts, and refused the connection. The good news: the fix is almost always mechanical once you know which link is missing. This guide diagnoses the real cause and fixes it at the right layer, not just the nearest one.

What the error actually means

The full stack trace usually reads: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Strip the jargon and it says: I received a leaf certificate, but I cannot connect it to a root CA in my truststore.

TLS certificates are validated as a chain. The server presents a leaf certificate for its hostname, which is signed by one or more intermediate CAs, which are ultimately signed by a root CA that ships in the JVM's truststore (the cacerts file). "Path building failed" means one of those links is missing or untrusted, most often a missing intermediate, sometimes a self-signed or internal cert whose root the JVM has never heard of.

The TLS certificate chain of trust

Find the real cause before touching anything

Do not import certificates blindly. First, look at what the server is actually sending. From the command line:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Read the output. If you see the leaf certificate but no intermediate certificates listed, the server is misconfigured, it is not sending its full chain, and that is the root cause. If the full chain is present but ends in a CA your JVM does not trust (a private/internal CA, or a self-signed cert), the fix belongs in the truststore. Use -servername so SNI returns the right certificate; a surprising number of PKIX failures are just the JVM getting a default vhost cert. You can also cross-check the public chain fast with the free SSL checker.

Fix it at the server (the root-cause fix)

If openssl showed a missing intermediate, fix the server, not every client. The proper repair is to configure the server to present the full chain: the leaf certificate followed by all intermediate certificates, in order, up to (but not including) the root. Most CAs provide a "fullchain" or bundle file for exactly this, point your web server, load balancer, or Java keystore at that instead of the bare leaf.

This matters because it is the lazy fix in the best sense: one change on the server fixes every client, browsers, curl, other JVMs, that would otherwise trip on the same gap. Importing the intermediate into one application's truststore patches a single caller and leaves every other client still broken. If the certificate itself has simply expired, that is a different problem; see our guide on the SSL certificate expired error.

Fix it at the client truststore (when you can't fix the server)

When the certificate is from an internal or private CA and adding it to trust is legitimate, import that CA, the root or intermediate, not the leaf, into a truststore. First grab the CA certificate (from your PKI team or by extracting it from the openssl output), then:

keytool -importcert -alias my-internal-ca -file ca.pem -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit

The default cacerts password is changeit. Prefer importing into a custom truststore and pointing your app at it with -Djavax.net.ssl.trustStore=/path/to/truststore.jks rather than editing the JVM-wide cacerts, so an upgrade or reinstall does not wipe your change. Import the CA, never the leaf certificate, pinning individual leaf certs means re-importing on every renewal.

Common gotchas that waste an afternoon

A handful of traps produce this exact error even when your certificate is fine. Check these before going deeper.

Wrong JAVA_HOME: you imported into one JDK's cacerts but the app runs under a different JDK. Confirm which java is actually executing and which cacerts it reads.
Corporate MITM proxy: a TLS-inspecting proxy re-signs traffic with a private root your JVM does not trust. Import the proxy's root CA into the truststore.
SNI mismatch: without -servername (or the equivalent in your HTTP client), the server may return a default certificate for the wrong host. Ensure your client sends SNI.
Stale or partial bundle: an intermediate CA was cross-signed or rotated and your server is still sending an old chain. Re-download the current fullchain from your CA.
Wrong truststore in use: a framework or container may override the truststore via system properties or env vars. Verify javax.net.ssl.trustStore is what you think it is.

Stop rediscovering it in production

PKIX failures are usually a certificate or chain problem that was visible days earlier, an expiring cert, a rotated intermediate, a chain that quietly lost a link. VigilDog monitors SSL/TLS certificates and their full chains continuously and alerts you before an expiry or a broken chain turns into a handshake exception in prod. Catching it as a warning email beats catching it as a 2am stack trace.