Debugging log · Networking

SSLHandshakeException: "Trust anchor for certification path not found"

An HTTPS call failed before it sent anything, with SSLHandshakeException and Trust anchor for certification path not found. The URL worked fine in my laptop's browser, which made it baffling. The device couldn't verify the server's certificate — not because the server is insecure, but because the chain that proves its certificate didn't fully reach a certificate authority the device trusts.

The short version: the device couldn't build a trusted chain from the server's certificate up to a root CA it knows. Usually the server is missing an intermediate certificate, or it uses a private/self-signed CA, or the device is too old to know a newer root. Fix the server's chain or trust the right CA properly — never disable certificate checking.

The error

javax.net.ssl.SSLHandshakeException:
  java.security.cert.CertPathValidatorException:
  Trust anchor for certification path not found.

How certificate validation works (briefly)

When your app connects over HTTPS, the server presents a certificate. The device trusts it only if it can build a chain from that certificate, through any intermediate certificates, up to a root CA in the device's trust store. If any link is missing or untrusted, the chain can't be completed and validation fails — that's the "trust anchor not found." It's a safety feature: it's what stops an attacker from presenting a fake certificate.

Cause 1 — the server is missing an intermediate certificate

This is the most common and most misleading one. Browsers often fetch a missing intermediate automatically or cache it, so the site looks fine in a browser — but Android doesn't, so the chain breaks on device. Test the server's chain with an SSL checker (SSL Labs or similar); if it reports an incomplete chain, the fix is on the server: configure it to serve the full chain including intermediates. This resolves it for every client, not just your app.

Cause 2 — a private or self-signed CA

If you're hitting an internal server with a self-signed certificate or a company CA the device doesn't know, validation correctly fails. The right fix is to trust that CA explicitly, scoped to that domain, via a network security config — not to turn off checking:

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">internal.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca" />
        </trust-anchors>
    </domain-config>
</network-security-config>

This trusts your CA for that host only, leaving normal validation intact everywhere else.

Cause 3 — an old device missing a newer root

Root CAs change, and older devices that stopped getting updates may not have a newer root your server's certificate chains to. If it fails only on old devices, that's the cause. Options: make sure the server serves intermediates (sometimes enough), or use a certificate from a CA with broader legacy device coverage.

Never "fix" this by trusting all certificates or installing a blank TrustManager that accepts anything. It's the most-copied dangerous answer online, it defeats HTTPS entirely, it exposes your users to interception, and Google Play rejects apps that ship an insecure TrustManager. Fix the chain or trust a specific CA for a specific domain instead.

How to pin down which cause

Works in a browser but not on device? Strongly suggests a missing intermediate — check the server chain with an external SSL test.
Hitting an internal/self-signed server? Trust the CA via network security config, scoped to the domain.
Fails only on old devices? Missing newer root — fix intermediates or change CA.
Confirm the real cause before coding — most of the time the fix belongs on the server, not in your app.

Domain and resource names above are examples — use your own, and prefer fixing the server chain where that's the cause.