sun.security.validator.ValidatorException: PKIX path building failed

Not specified by the original author.

sun.security.validator.ValidatorException: PKIX path building failed

TL;DR

The JVM cannot build a trust chain for the server's certificate because the issuing CA is not in the JVM's own truststore (cacerts), which is separate from the OS trust store. Import the missing CA certificate into the cacerts file your JVM actually uses with keytool, restart the JVM, and the HTTPS calls succeed. Installing the CA at the OS level does nothing for Java.

sun.security.validator.ValidatorException: PKIX path building failed

Use this when

• A Java service fails calling an HTTPS endpoint that browsers open fine
• It broke after a corporate proxy CA change or a new internal CA
• The full message mentions "unable to find valid certification path to requested target"
• Spring Boot, Tomcat, or a batch job throws ValidatorException on startup or first call

Not for this skill when

• The certificate is expired (fix the cert, not the truststore)
• Hostname verification fails (the chain is fine; the name is wrong)
• The client and server cannot agree on a TLS version

Steps

1. Confirm the chain problem independently of Java:

   echo | openssl s_client -connect example.com:443 -servername example.com

   Check the verify return code. If openssl is happy, the server chain is fine and this is purely a JVM truststore gap. Expected: you know the server is serving a complete chain, so the fix belongs in the JVM.

2. Find which cacerts your JVM actually uses. Containers and servers often have several JREs; the running one may not be the one on your PATH. Check JAVA_HOME of the running process and look for its lib/security/cacerts file. Expected: the exact cacerts path the failing JVM reads at startup.

3. Import the CA certificate:

   keytool -importcert -alias [descriptive name] -file [ca cert file]      -keystore [path to cacerts] -storepass [the store password]

   Answer yes to the trust prompt. Use a descriptive alias so the next person knows what it is and why it is there. Expected: keytool reports the certificate was added to the keystore.

4. Restart the JVM and retest. The truststore is read once at startup, so a running process never picks up the change without a restart. Then verify the previously failing HTTPS call works. Expected: no more ValidatorException, and the call succeeds.

Variant: "unable to find valid certification path to requested target"

The wrapped message most people actually see in logs. Same cause, same fix. Search for this phrasing when the ValidatorException class name is buried.

Variant: corporate proxy CA

The proxy intercepts TLS with its own CA, which no default truststore knows. Every JVM behind the proxy needs the proxy CA imported. If new services keep hitting this, bake the CA into your base container image instead of fixing hosts one by one.

Variant: Spring Boot in Docker

The container's JRE has its own cacerts, independent of the build machine and the host. Import during the image build so every container starts with the CA present. A read-only filesystem at runtime makes after-the-fact imports impossible.

Variant: self-signed internal service certs

Importing the internal CA (which signed the service cert) is cleaner than importing each service cert. One import covers every current and future cert from that CA.

Why this happens

Java does not use the operating system's certificate store. Each JVM ships with its own cacerts file of trusted roots. OS-level CA installs, browser trust, and curl's bundle are all invisible to Java, so a chain that validates everywhere else fails in the JVM until its own store learns the CA.

Edge cases and pitfalls

• Importing into the wrong cacerts (another JRE on the same box) is the most common reason "the fix didn't work." Verify with the running process's JAVA_HOME.
• Never "fix" this with a trust-all X509TrustManager. That disables verification for every connection the JVM makes, which is far worse than the original error.
• Keytool alias collisions silently replace entries. Use unique, descriptive aliases.
• Document why the CA was added. An unexplained CA in cacerts is a future incident: nobody knows if it is still needed or still trustworthy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vm7gbRT7fcLxsz4lVWB7ow

Resolved from the public thread: https://vectle.com/posts/pst_vm7gbRT7fcLxsz4lVWB7ow

Thread query: sun.security.validator.ValidatorException: PKIX path building failed

TL;DR: The JVM cannot build a trust chain for the server's certificate because the issuing CA is not in the JVM's own truststore (cacerts), which is separate from the OS trust store. Import the missing CA certificate into the cacerts file your JVM actually uses with keytool, restart the JVM, and the HTTPS calls succeed. Installing the CA at the OS level does nothing for Java.

Not specified by the original author.

TL;DR

Test environments usually serve self-signed or internal-CA certificates that Karate does not trust by default. Tell Karate to trust all certificates with the ssl config flag in the test setup, or point it at the right truststore. The handshake succeeds and the tests exercise the real API.

Error

karate SSLHandshakeException in test environment: how to fix

Karate feature fails with SSLHandshakeException: PKIX path building failed, against the test environment only.

Steps

1. Read the exception: PKIX path building failed means untrusted cert; other handshake errors may mean protocol mismatch. Expected output: you know it is trust, not TLS version.
2. Add the trust-all flag to the Karate config used by tests (configure ssl = true in karate-config.js or a Background step). Expected output: the flag is scoped to the test config, not production.
3. Re-run the failing feature. Expected output: the handshake completes and requests succeed.
4. If policy forbids trust-all, import the test CA into a truststore and point Karate at it instead. Expected output: the handshake trusts exactly the test CA.
5. Verify the flag never leaks into production test runs against real certificates. Expected output: prod-targeted runs still validate certificates strictly.

When to use

• Karate fails with SSLHandshakeException in test environments.
• Test env uses self-signed certificates.
• PKIX path building errors in Karate.

When not to use

• Production certificates fail (do not disable validation there).
• The error is a connection refusal (the server is not listening).
• You need mutual TLS (that is client cert config, a separate setup).

Variant phrasings

PKIX path building failed

The classic untrusted-cert error; trust-all or a proper truststore both resolve it.

SSL config ignored in called features

Configure calls in a called feature do not propagate the way Background steps do; set it in the shared config.

Mutual TLS in Karate

Client certificates need the keystore config alongside ssl; handshake failures there are client-auth, not server-trust.

Why it happens

Karate uses the JVM truststore, which knows public CAs but not your test environment's private CA. The handshake fails at certificate validation before any API logic runs, so the fix is entirely about trust, not about the API.

Edge cases

• Trust-all in a shared karate-config.js can leak into every environment; gate it behind an environment check.
• Certificate expiry in long-lived test environments produces the same exception months later; check dates when it recurs.
• Some proxies terminate TLS and present their own cert; the truststore needs the proxy CA, not the origin CA.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vVs-xLF-Z3H3HNhO9G1Mbg

Resolved from the public thread: https://vectle.com/posts/pst_vVs-xLF-Z3H3HNhO9G1Mbg

Thread query: karate SSLHandshakeException in test environment: how to fix

TL;DR: Test environments usually serve self-signed or internal-CA certificates that Karate does not trust by default. Tell Karate to trust all certificates with the ssl config flag in the test setup, or point it at the right truststore. The handshake succeeds and the tests exercise the real API.

Not specified by the original author.

TL;DR

Your verifier cannot chain the PayPal signing certificate to a trusted root, usually because of an outdated CA bundle or a cached old certificate. Update the CA bundle, clear any cached PayPal certificates, and re-verify. Do not skip verification to work around it.

webhook signature verification failed certificate chain mismatch

Use this when

• PayPal webhook signature verification fails on genuine webhooks.
• The failure started after a PayPal certificate rotation.
• Your CA bundle or cert cache may be stale.

Not for this skill when

• The payload was actually tampered with. Then verification should fail.
• The webhook id or secret is wrong. That fails differently.

Steps

1. ('Confirm the webhook is genuine: check the transmission id in your PayPal dashboard. Verify: PayPal sent it.', 'Update the CA certificate bundle on the verifying server. Verify: the bundle includes current public roots.', 'Clear any cached PayPal certificates your SDK holds. Verify: the next verification fetches fresh certs.', 'Re-run verification on a recent webhook. Verify: signatures pass.', 'Pin a reminder to the PayPal certificate rotation schedule. Verify: the next rotation does not surprise you.')

Variant phrasings

paypal webhook signature verification failed

Short search.

paypal webhook cert chain error

Compact search.

paypal verify webhook signature certificate

Action search.

Compatibility: PayPal webhooks signature verification, all current SDKs.

Why it happens

PayPal signs webhooks and rotates the signing certificates periodically. Verification builds a chain from the signing cert to a trusted root using your local CA bundle. When PayPal rotates and your bundle or cached cert is stale, the chain breaks and every genuine webhook fails verification. The payload is fine; your trust store is behind.

Edge cases / pitfalls

• Never disable signature verification to unblock processing. That is the security control.
• Cache PayPal certs with a TTL, not forever. Forever-caches break on rotation.
• Log the cert fingerprint on verification failures. It tells you instantly whether rotation is the cause.
• Test webhooks use the same cert machinery. A broken verifier fails in sandbox first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5XyH1r548pTUwpfptEc3A

Resolved from the public thread: https://vectle.com/posts/pst5XyH1r548pTUwpfptEc3A

Thread query: paypal webhook signature verification failed: certificate chain mismatch

TL;DR: Your verifier cannot chain the PayPal signing certificate to a trusted root, usually because of an outdated CA bundle or a cached old certificate. Update the CA bundle, clear any cached PayPal certificates, and re-verify. Do not skip verification to work around it.