🚨 Kafka Error Guide: 'PKIX path building failed' Unable to Find Valid Certification Path

Exact Error Message

This failure appears when the TLS handshake negotiated fine but the client cannot build a trusted chain to the certificate the broker presented:

[2026-06-29 12:18:04,330] ERROR [Producer clientId=billing-producer] Connection to node
-1 (broker-01.kafka.internal/10.0.4.21:9093) failed authentication due to: SSL handshake
failed (org.apache.kafka.clients.NetworkClient)

org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
    at sun.security.validator.Validator.validate(Validator.java:264)

On the broker side, when the client certificate cannot be validated (mTLS), you see the matching fatal alert:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Related variants include “certificate_unknown”, ValidatorException: PKIX path building failed, and “unable to find valid certification path to requested target”.

What the Error Means

PKIX path building failed is a trust-chain problem. The handshake successfully negotiated a protocol and cipher; the peer then presented a certificate, but the validating side could not link that certificate up to a trusted root in its truststore. Either the CA (or an intermediate) is missing from the truststore, or the peer sent an incomplete chain that omits an intermediate.

This is the opposite end of the TLS spectrum from handshake_failure. There, the parties could not agree how to talk. Here, they agreed and exchanged certificates, but trust verification failed. Direction matters: a client-side PKIX path building failed means the client does not trust the broker cert; a broker-side bad_certificate means the broker does not trust the client cert (mTLS).

Common Causes

• CA root missing from the truststore — the validating side has no anchor for the peer’s issuer (most common).
• Incomplete chain: the broker keystore contains the leaf but not the intermediate CA, so the client cannot bridge to the root it trusts.
• Wrong truststore referenced by ssl.truststore.location, or the JVM default cacerts used instead of the internal CA store.
• Self-signed broker certificate never imported into the client truststore.
• Renewed/rotated CA where new certs chain to a root the truststore does not yet contain.
• mTLS: the client’s keystore presents a cert whose CA is absent from the broker’s truststore, yielding bad_certificate on the broker.

How to Reproduce the Error

Connect with a truststore that does not contain the broker’s issuing CA:

cat > /tmp/notrust-client.properties <<'EOF'
security.protocol=SSL
ssl.truststore.location=/tmp/empty-truststore.jks
ssl.truststore.password=changeit
EOF

kafka-broker-api-versions.sh --bootstrap-server broker-01.kafka.internal:9093 \
  --command-config /tmp/notrust-client.properties

The handshake negotiates, then fails with PKIX path building failed: unable to find valid certification path to requested target because the empty truststore trusts nothing.

Diagnostic Commands

All commands below are read-only.

# Show the full chain the broker actually presents (does it include intermediates?)
openssl s_client -connect broker-01.kafka.internal:9093 -showcerts </dev/null 2>&1 | \
  grep -E 'subject=|issuer=|Verify return code'

# List the CA entries in the client truststore — is the issuing CA present?
keytool -list -v -keystore /etc/kafka/ssl/truststore.jks -storepass changeit | \
  grep -E 'Alias name|Owner|Issuer'

# Inspect the broker leaf cert's issuer to know which CA must be trusted
openssl s_client -connect broker-01.kafka.internal:9093 </dev/null 2>&1 | \
  openssl x509 -noout -issuer -subject

# Confirm which truststore the client config points at
grep -E 'ssl.truststore.location|ssl.truststore.type' /tmp/notrust-client.properties

# For mTLS bad_certificate: check the broker truststore for the client's CA
keytool -list -keystore /etc/kafka/ssl/broker-truststore.jks -storepass changeit

A Verify return code: 21 (unable to verify the first certificate) from openssl s_client confirms a missing-anchor/incomplete-chain trust problem rather than negotiation.

Step-by-Step Resolution

1. Confirm it is a trust problem. PKIX path building failed / bad_certificate means trust, not negotiation (handshake_failure) or expiry (CertificateExpiredException).
2. Identify the broker cert’s issuer with openssl s_client | openssl x509 -issuer. That CA (and any intermediate) must be in the validating side’s truststore.
3. Inspect the truststore with keytool -list -v. If the issuing CA is absent, that is the gap.
4. Check chain completeness. If openssl s_client -showcerts shows only the leaf, the broker keystore is missing its intermediate; the chain must include it.
5. Point at the correct truststore. Verify ssl.truststore.location references the internal CA store, not the JVM default cacerts.
6. For mTLS bad_certificate, ensure the broker truststore contains the client certificate’s CA.
7. Re-test with openssl s_client and then kafka-broker-api-versions.sh --command-config to confirm Verify return code: 0 (ok).

Importing CA certs into a truststore is a mutating action handled by an operator; the steps above identify exactly which CA is missing.

Prevention and Best Practices

• Distribute the internal CA (and intermediates) to every client truststore via config management, not by hand.
• Always build broker keystores with the full chain (leaf + intermediates) so clients can verify against just the root.
• Reference an explicit, internal truststore — never silently fall back to the JVM default cacerts for internal CAs.
• Coordinate CA rotations: add the new CA to all truststores before issuing certs that chain to it.
• Add an openssl s_client synthetic check that asserts Verify return code: 0 from each client network. The free incident assistant can pinpoint the missing CA from the verify output. See more in the Kafka guides.

Related Errors

• SSLHandshakeException: handshake_failure — negotiation failed before trust evaluation.
• CertificateExpiredException — the chain is trusted but a cert has expired.
• No subject alternative names found — chain is trusted but the hostname does not match.
• SslAuthenticationException / SSL channel closed — abrupt close, often a protocol mismatch on the listener.

Frequently Asked Questions

What does “unable to find valid certification path” actually mean? The validating side could not link the presented certificate to a trusted root. The issuing CA (or an intermediate) is missing from its truststore.

Client says PKIX failed but the broker says bad_certificate — which is it? Both describe the same trust failure from each side. Client-side PKIX means the client distrusts the broker cert; broker-side bad_certificate (mTLS) means the broker distrusts the client cert.

My truststore has the root CA but it still fails. Why? The broker is probably sending an incomplete chain (leaf only) without the intermediate, so the client cannot bridge to the trusted root. Add the intermediate to the broker keystore.

Is this the same as an expired certificate? No. Expiry throws CertificateExpiredException. PKIX path building failure is specifically about a missing/untrusted issuer.

How do I see the broker’s chain without a Java client? openssl s_client -connect host:9093 -showcerts prints every certificate the broker presents, so you can verify the intermediate is included.