Why does my Java client report 'unable to find valid certification path'? - Certificate Management Service

Java applications throw javax.net.ssl.SSLHandshakeException: PKIX path building failed when either the server's certificate chain is incomplete or the client's JDK truststore doesn't include the required root certificate. Diagnose which cause applies, then follow the matching fix.

Symptoms

A Java application connecting to an HTTPS endpoint fails with:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The same HTTPS address works in Chrome or Firefox (showing a security lock icon), while non-browser clients — Java applications, curl, wget — report a TLS handshake failure or certificate verification error.

Why browsers succeed but Java fails: Modern browsers implement Authority Information Access (AIA) chasing. When a server sends an incomplete certificate chain, browsers automatically download the missing intermediate certificates to complete it. Java clients do not — they require the server to send the full chain during the TLS handshake.

Causes

Cause 1: Incomplete server certificate chain. The server sends only the server certificate (domain name certificate) and omits the intermediate certificates that link it to a trusted root. Java clients cannot build the trust chain and reject the connection.
Cause 2: Outdated JDK truststore. The server sends a complete chain, but the client's JDK truststore ($JAVA_HOME/jre/lib/security/cacerts) doesn't include the root certificate or cross-signed root certificate used by the chain. This typically happens with older JDK versions. For example, after DigiCert switched from the G1 root to the G2 root, older JDK versions don't trust the G2 root. For details, see DigiCert Root Certificate Replacement Announcement.

Diagnose the server

Before applying a fix, confirm whether the server is sending a complete certificate chain. Two options are available:

Option A: OpenSSL command (requires OpenSSL)

Run the following command, replacing your.domain.com:443 with your actual server endpoint.

# Connect to the server and display the certificate chain it provides
openssl s_client -connect your.domain.com:443 -showcerts

Option B: SSL Labs Server Test (no CLI required)

Go to https://www.ssllabs.com/ssltest/, enter your domain, and check the Chain issues field in the report. A value of None means the chain is complete; Incomplete or Extra download means the server is missing intermediate certificates.

Interpret OpenSSL output

Incomplete chain (Cause 1)

The Certificate chain section shows only one entry (depth=0). The verify return code is non-zero:

Certificate chain
 0 s:/CN=your.domain.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
---
Server certificate
-----BEGIN CERTIFICATE-----
(Server certificate content)
-----END CERTIFICATE-----
...
Verify return code: 20 (unable to get local issuer certificate)

Complete chain (healthy)

The output contains multiple certificates forming an ordered chain from depth=0 (server certificate) to depth=1 (intermediate certificate). The verify return code is 0 (ok):

Certificate chain
 0 s:/CN=your.domain.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
   i:/C=US/O=DigiCert Inc/CN=DigiCert Global Root CA
---
...
Verify return code: 0 (ok)

If the chain is complete but the Java client still fails, skip to Fix an outdated JDK truststore.

Fix an incomplete server certificate chain

Reconfigure the server to send the full chain. This applies to web servers such as NGINX, Apache, and Tomcat, and load balancers such as Server Load Balancer (SLB).

Get the full chain certificate package from your certification authority (CA). This file typically contains the server certificate followed by all intermediate certificates, and is usually named fullchain.pem or chain.pem.

Verify the order of certificates in the file: the server certificate must come first, followed by each intermediate certificate.

Note: If the certificates are in the wrong order, your web server may fail to start.

-----BEGIN CERTIFICATE-----
(Your server certificate content)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate 1 content)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Intermediate certificate 2 content, if it exists)
-----END CERTIFICATE-----

Update your web server or gateway SSL configuration to point to this complete certificate package file, then restart the service.
Re-run the OpenSSL command or SSL Labs test to confirm Verify return code: 0 (ok) and no chain issues.

Fix an outdated JDK truststore

If the server chain is complete but the Java client still fails, the JDK truststore is missing the required root certificate.

Upgrade the JDK (recommended)

Upgrade to the latest Long-Term Support (LTS) patch release of your JDK version — for example, the latest update for JDK 8, JDK 11, or JDK 17. Newer patch releases include an updated root certificate library that resolves CA root replacement issues and provide important security fixes.

Manually import the root certificate (temporary workaround)

If upgrading the JDK immediately isn't possible, import the missing root certificate into the JDK's cacerts truststore.

Download the missing root certificate file. See Download root certificates.

Run the following keytool command. Replace the placeholders with actual values. The default truststore password is changeit.

Placeholder	Description
`<give-a-unique-alias>`	A unique name for this certificate entry in the truststore
`<path-to-root-ca.crt>`	The local path to the downloaded root certificate file
`$JAVA_HOME`	Your Java installation directory

# Replace <path-to-root-ca.crt> with the path to the root certificate file
# Replace $JAVA_HOME with your Java installation directory
keytool -import -alias <give-a-unique-alias> -keystore $JAVA_HOME/jre/lib/security/cacerts -file <path-to-root-ca.crt> -storepass changeit

Restart the Java application and verify that it can now connect to the HTTPS endpoint.

Best practices

Deploy the full chain on every certificate update. Each time you renew or replace a certificate, deploy fullchain.pem (or its equivalent), not just the domain name certificate. A process that works with the old certificate can silently break if an intermediate certificate changes.
Monitor certificate health proactively. Set up public domain name monitoring to get alerts before certificate issues cause downtime.