This error means Java's own trust store (distinct from your operating system's, and from any browser's) doesn't have the necessary root or intermediate certificate to validate the chain — common when connecting to a server using a newer or less common CA that hasn't yet been added to an older Java installation's bundled trust store.
The fix
keytool -import -alias mycert -file intermediate.pem \
-keystore $JAVA_HOME/lib/security/cacertsThis manually imports the missing certificate into Java's trust store (the default password is typically changeit, though it's worth changing on a production system). Alternatively, upgrading to a more current Java version often resolves this automatically, since newer Java releases ship with more current bundled trust stores.
What PKIX path building actually refers to in this specific Java error
PKIX path building is Java's terminology for the same chain-validation process covered throughout this site — this error is Java's specific, verbose way of reporting the same unable-to-get-local-issuer-certificate class of problem, just surfaced through Java's particular certificate validation terminology and exception structure.
How to add a certificate to Java's trust store to resolve this
Using Java's keytool utility with the -import flag to add the specific missing CA certificate to your JVM's cacerts trust store resolves this error when the underlying cause is a genuinely missing trusted root, distinct from cases where the actual fix needs to happen server-side on an incomplete chain instead.
What the specific keytool command looks like for adding a missing certificate
Running keytool -import -alias somealias -file certificate.crt -keystore $JAVA_HOME/lib/security/cacerts adds a specific certificate to Java's default trust store, using the default keystore password (changeit, unless changed) — a command worth having readily available given how often this specific fix is needed.
How this error's Java-specific terminology maps to more familiar TLS concepts
PKIX path building is Java's term for chain validation, a trust anchor is Java's term for a trusted root certificate, and this specific error is Java's way of reporting the same unable-to-get-local-issuer-certificate class of problem covered in more general terms throughout the rest of this site.
A final note for teams managing multiple Java services
For a team managing multiple Java-based services, standardizing how and when your shared JVM trust stores get updated, rather than handling each occurrence of this error as an isolated incident, reduces how often this specific, well-understood error needs to be independently rediscovered and fixed by different team members.
What the exact keytool command syntax looks like with all required parameters explained
The full command keytool -importcert -alias yourAlias -file /path/to/cert.crt -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit requires you to substitute your specific certificate file path and choose a memorable alias — the default password changeit is standard but should ideally be changed in any security-conscious production environment.
How different Java distributions can have different default trust store locations
OpenJDK, Oracle JDK, and various vendor-specific Java distributions (Amazon Corretto, Eclipse Temurin) can have slightly different default cacerts file locations relative to JAVA_HOME — running echo $JAVA_HOME first, then checking that specific installation's lib/security directory, confirms the correct path for your particular Java distribution.
A quick closing checklist
A quick closing checklist covers confirming your specific JAVA_HOME and cacerts location, using keytool to import any genuinely missing certificate, and documenting the process for your team given how often this specific fix tends to be needed repeatedly.
Why containerized Java applications need their own specific attention to this issue
A Java application running inside a container has its own independent JVM and trust store, separate entirely from the host system's — a fix applied to your host machine's Java installation has no effect on a containerized Java application, which needs the same fix applied inside its own specific container image.