Trust anchor for certification path not found

Where you see it

In Android apps, in Logcat or in the app’s error reporting, whatever HTTP library the app uses: OkHttp, Retrofit, HttpsURLConnection, Volley, and the Android side of Flutter and React Native apps.

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

The text comes from Android’s TLS provider, Conscrypt (TrustManagerImpl.java), and the Android documentation shows it in Security with network protocols.

What it means

A trust anchor is a root certificate that the app trusts. To accept the server, Android must build a certificate chain from the server’s certificate, through any intermediates, to one of those roots. Here it could not. The Android documentation lists three common reasons: the CA that issued the server’s certificate is unknown, the certificate is self-signed, or the server does not send its intermediate.

By default, apps trust the CAs that came with the system. Apps that target Android 7.0 (API level 24) or higher do not trust CAs that users install, unless the app opts in (network security configuration). So a root that works in the phone’s browser may still fail inside an app.

Likely causes

The server does not send its intermediate certificate

Desktop browsers can fetch a missing intermediate or may have cached it from another site, so the site looks fine there. An Android app, in the words of the Android documentation, “isn’t as tolerant”. Confirm by counting the certificates the server sends:

openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

1 means only the server’s own certificate arrives. Fix it on the server: serve the certificate followed by its intermediate (How to build the full chain file your server needs). The Android documentation gives the same fix. No app change is needed.

The server uses a private CA or a self-signed certificate

Internal and test APIs often use a company CA or a self-signed certificate that is not among the system CAs. Fix: let the app trust that CA, for its own domains only, with a network security configuration. Put the CA certificate (PEM or DER) in res/raw/my_ca, and add res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

Point to it from the manifest with android:networkSecurityConfig="@xml/network_security_config" on the <application> element. For a self-signed server, prefer giving it a certificate from a private CA, so the app trusts the CA rather than one server certificate.

The device or user trusts a root, but the app does not

A company root or a debugging proxy’s root installed by the user is not trusted by most apps (see above). For debug builds only, a <debug-overrides> section with its own <trust-anchors> adds trusted CAs that apply only when the app is debuggable. For production, trust the company CA for its domains as shown above.

The device is too old to know the root

Old Android versions no longer receive root updates, so they miss newer roots. For example, Let's Encrypt's cross-signed chain for old Android devices expired (30 September 2024). Confirm which root the server’s chain ends at (the last i: line of openssl s_client -showcerts), and test on a current device. Fix: if you must support such devices, the app can trust the needed root for its own domains through the network security configuration, or the server can use a certificate from a CA those devices trust.

Check yours

Try it: Chain checkerOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

Paste the chain

Try a sampleChoose a sample…A complete chain: leaf, intermediate and rootA server that forgets its intermediateA chain in the wrong orderA self-signed root CA

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

Every certificate the server sends, leaf first. The output of openssl s_client -showcerts -connect example.com:443 works as it is: we ignore the text around the certificates.

Check the chainClearChoose a file

Paste the certificates from openssl s_client -showcerts. The checker shows whether the intermediate is missing and which root the chain needs.

Learn why

• Who do we trust? CAs, trust stores and self-signed certificates: system stores, user stores and app-specific trust.
• Certificate chains and path validation: why the intermediate must be sent.
• Two roads to the same root: cross-signing and root expiry: why old devices need cross-signed chains.
• The same problem in Java: PKIX path building failed.

In the gameLevel 12: Who do we trust?Registry of Roots, Keystone. In development