We recently switched from HttpUrlConnection to OkHttp (v4.12.0) on Android and started seeing CertPathValidatorException: Trust anchor for certification path not found from a small percentage of our users. I've read that this is possible for older versions of Android, however we are seeing it across all versions, Android 15 and below, with majority from Android 14-12 and common devices like Samsung, Google & Motorola.

Our usage of OkHttp is basically vanilla implementation.

The SSL certificate is obviously valid and up to date (not self signed) and we encounter no issues during testing. This also never happened when we were using HttpUrlConnection.

What could be causing this and any advice on how to resolve this would be greatly appreciated. Thanks!

We recently switched from HttpUrlConnection to OkHttp (v4.12.0) on Android and started seeing CertPathValidatorException: Trust anchor for certification path not found from a small percentage of our users. I've read that this is possible for older versions of Android, however we are seeing it across all versions, Android 15 and below, with majority from Android 14-12 and common devices like Samsung, Google & Motorola.

Our usage of OkHttp is basically vanilla implementation.

The SSL certificate is obviously valid and up to date (not self signed) and we encounter no issues during testing. This also never happened when we were using HttpUrlConnection.

What could be causing this and any advice on how to resolve this would be greatly appreciated. Thanks!

• android
• ssl
• okhttp

Share Improve this question Follow asked Mar 21 at 2:45 AlexVPerlAlexVPerl 8,02688 gold badges5454 silver badges8989 bronze badges 5

• If it is a small percentage of users with no clear sign for a specific android version or vendor, then it could be HTTPS interception at the users site. This is for example common in corporate environments to detect malware even in HTTPS connections, but it could also be done in schools etc to "protect the children" from unwanted content. Such interception means that it is not your certificate which is provided to the app but as different certificate issued from a local interception CA not trusted by default by the device. – Steffen Ullrich Commented Mar 21 at 5:48
• Is it possible that you confirm intermediate CA certificates on the application servers are newest and consistent? Are all CA certificates in the server certificate chain downloaded by the client? There may be some cases that current intermediate CA certificate on the client store is problematic and the new version is not sent by the server to the client, hence causes a trust chain issue. – ErkinD39 Commented Mar 21 at 6:38
• @SteffenUllrich thank you for replying. This is interesting to know. But in that case wouldn't it affect all web sites for the device when accessing from that type of environment? Our cert is issued by Google CA btw. – AlexVPerl Commented Mar 21 at 19:33
• @ErkinD39 Thanks. I think what you're describing is probably what is happening (an incomplete cert chain), based on our research of this exception. We don't include the certificate in the client for security reasons. But our cert is issued by Google CA. – AlexVPerl Commented Mar 21 at 19:37
• I see community.cloudflare/t/… is probably related. Glad you are discussing with them. – Yuri Schimke Commented Mar 30 at 11:07

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

In terms of investigating this with OkHttp, you'll need to capture both the Certificates returned by the server and also the Android Platform accepted issuers. Then either log them, or explain why it's not being accepted.

SSL Handshake certs - This class is a capturing TrustManager which delegates to the original one. If you apply this, then even if it fails you'll be able to grab hold of the certs the server provided.

https://github/cashapp/certifikit/blob/8a4bae82031dfecc5ace46bd77763313961379ad/certifikit-cli/src/jvmMain/kotlin/app/cash/certifikit/cli/okhttp/CapturingTrustManager.kt#L4

class CapturingTrustManager(
  val delegate: X509ExtendedTrustManager,
  val captured: MutableMap<String, List<X509Certificate>>
) : X509ExtendedTrustManager() {

Android Platform Certs -

Platform.get().platformTrustManager().acceptedIssuers.map {
  CertDetails(it)
}

certs.forEach { 
  println(it)
}

Utils

val X509Certificate.fingerprint: String
  get() {
    return MessageDigest.getInstance("SHA-256").run {
      digest(encoded)
    }.toHexString()
  }

data class CertDetails(
  val fingerprint: String,
  val expires: String,
  val subject: String?,
  val issuer: String?,
) {
  constructor(cert: X509Certificate) : this(cert.fingerprint, cert.notAfter.toString(), cert.subjectX500Principal?.toString(), cert.issuerX500Principal?.toString())
}

You basically want to see that there is a chain from

1. HTTP Server certificate (in handshake)
2. Multiple Intermediate (in handshake)
3. Trusted CA cert (in platform)

This would require a test build of the app, and on failure collect this information. You might want to also log whether a proxy was being used, the local datetime of the device and the DNS results.