(original title: Do some Android vendors ship their own SSL stack implementation?)

We've been having (in production) a peculiar HTTPS-related issue lately in our Android app.

All calls to our domain from within a WebView fail in our Android app, due to an SSL certificate validation issue. But this happens only in very specific combination of circumstances:

  • only on Androids (desktop browsers, iOS are fine with our cert)
  • only inside a WebView (works fine in Chrome, default Android browser, and when doing HttpsURLConnection from Java code)
  • only on some devices (Samsung Galaxy Edge S6 with Android 6, HTC One M8 with Android 5); other devices (Sony/Android 4.4, Lenovo/Android 4.4, Motorola/Android 5, Huawei/Android 6, Nexus/Android 6) are not affected

Other important info:

  • note that the issue happens on Android 5/6 which have an auto-updating WebView. For example, I reproduced issue in a fully up-to-date Samsung Galaxy Edge S6 (non-ISP-branded), Android 6.0.1 with security patches from 1 October 2016. The webview is very modern (Chrome 53)

  • note that I checked the CA store and the root cert that signed our cert is in the store of the affected devices, with the same name and sha1 fingerprint.

  • I used to have custom (user) CA certs (generated by Fiddler and installed manually by me to be able to decrypt HTTPS for debugging) on my devices, but for the sake of test, I removed them, and now the user CA store is empty on all devices, but issue persists

  • I tested some 60 high profile websites, and the issue is reproducible for several of them too (including https://www.amazon.com) on the two affected devices (the set of websites rejected by Samsung and HTC is overlapping, but not exactly the same). Some of those affected websites have the same VeriSign cert as the root cert of the chain as we do, but this root cert is present in the CA store of the device as mentioned previously.

  • Our SSL cert is quite good according to SSLLabs, and the issue happens on amazon.com which apparently has very good server/cert config (click)

  • While we reproduced the issue in our device lab, we also got quite a few negative Play Store reviews that look like the same issue (all from Samsungs, but this correlates with our user base). However the app works fine for most of people, as we get mostly 5 star reviews every day.

Next steps that we're taking:

  • We're trying to embed the cert inside the Android app and make Android explicitly trust it, but since WebView and HTTPSUrlConnection behave differently, we're not sure if this will work

  • If this doesn't work, as a last resort we'll also probably try to override WebViewClient.onReceivedSslError with a custom implementation which will inspect the cert and trust it if it has the same fingerprint as our cert

  • any better options?


  • some Android shipping customized SSL stack in their versions of Android? (but why Samsung and HTC would exhibit a very similar behavior)
  • does Chrome have separate CA store than the Android device?
  • some other apps installed on the affected Android devices that mess up with the WebView in my app?
  • anything else?


I reproduced the issue on the following websites:

  • www.microsoft.com (Symantec cert)
  • www.amazon.com (Symantec cert)
  • mail.ru (GeoTrust cert - Symantec subsidiary)
  • two others with Symantec or GeoTrust certs
  • www.theguardian.com (cert doesn't seem to be Symantec-related)

So most probably the issue comes from webview bug that EricLaw pointed. Guardian case seems to be some another issue however.

Edit 2:

I confirmed the issue was due to the bug mentioned by Eric. We changed our SSL cert provider and it solved the issue.

  • 1
    While your problem description lacks much detail one could explain the given detail solely with different CA in the trust store. This means they still could use the same SSL stack but only differ in the contents of the trust store. Commented Dec 8, 2016 at 10:40
  • I checked the CA store and the root cert we use is in the store of the affected devices, with the same name and sha1 fingerprint.
    – jakub.g
    Commented Dec 8, 2016 at 11:25
  • 2
    Maybe you could add also details about the theory you have about the rejection so that one could determine if this is an issue of the SSL stack or something else (i.e. issue of Webview and not the SSL stack since Chrome works fine). Commented Dec 8, 2016 at 11:54
  • our theory was that the issue might have been due to the server unnecessarily sending the root cert and the implementation being over-eager to reject it for some reason. However I checked most of top-100 websites in the world, and in fact https://www.amazon.com and https://mail.ru (only those two) exhibit the same behavior, while having flawless certs and not sending the root cert from server, so I think my theory fell apart...
    – jakub.g
    Commented Dec 8, 2016 at 15:01
  • webview implementations don't get updated anywhere near as often as browsers, in some cases never or only with major OTA upgrades. they are also always very behind "real browsers" in terms of features and security. afaik, there's not a whole lot devs can do about it beside throw more mud at the wall and see what sticks, forking per-device as needed.
    – dandavis
    Commented Dec 8, 2016 at 22:08

2 Answers 2


My bet is that the CT log expired. See https://www.chromium.org/developers/androidwebview/webview-ct-bug and https://groups.google.com/a/chromium.org/forum/m/#!topic/net-dev/d3bHcocG-NM

  • Yes, upgrading WebView helps for me.
    – Velda
    Commented Nov 29, 2017 at 20:52

In case of the traffic generated by the Facebook application, you will find a custom implementation, called Zero, and

"they really want 0-RTT, but tls 1.3 is not here, so they modified QUIC crypto to make it happen on top of TCP: it's called Zero."

Source here

This traffic can be captured with any up-to-date iOS or Android device running Facebook App. A pcap is available here

  • 1
    Android uses Facebook Zero? Your link does not say that.
    – schroeder
    Commented Dec 9, 2016 at 21:53
  • information available at the paragraph called:TLS at the scale of Facebook
    – MarTino Trevisan
    Commented Dec 9, 2016 at 22:03
  • 1
    yep I had read that - does not say Android uses Zero
    – schroeder
    Commented Dec 9, 2016 at 22:04
  • Run a a wireshark on your device and you will see that
    – MarTino Trevisan
    Commented Dec 9, 2016 at 22:06
  • 1
    The question was is some Android vendors ship with a custom SSL stack, not if some targets use a custom SSL stack. Nothing you are saying appears to relate to Android or the OP's situation at all.
    – schroeder
    Commented Dec 9, 2016 at 22:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .