My company uses a private PKI to handle such scenarios such as

  • Mutual auth (TLS) to a website using client certificates
  • SSL web server certificates on an Intranet (once a VPN session is established.)
  • S/MIME secure email.
  • Activesync authentication

When upgrading Android to Kitkat the presence of a non-default root certificate results in these warnings

enter image description here and enter image description here

It is possible to remove this warning for a root user, or by uploading the certificate into Google Apps (and paying $5 per user/month), however I'm looking for a solution that does not incur this unnecessary cost.

Several people have posted this as a defect in the FOSS code, however the issue #62076 (starred by 121 people) has been closed as "by design". Edit: This issue has been reopened in issue 82036 Please star it to vote as an issue, or comment as needed.

Through testing I verified that this error still appears when using Name Constraints, and limiting the EKU purpose of the new Root CA. (S/MIME, client authentication, etc).

  • Is there any way to add a certificate to the trusted roots on an Android phone that does not create this error? (in current or future version)

  • Are non-default trusted roots, in practice, more problematic than the default CA list (in other words is Google solving the wrong problem?)

  • Is it reasonable to allow a root cert that is properly constrained (at the root) by EKU usages, or Name Constraints to generate a different warning or set of approval dialogs?

  • 1
    Well, it's not wrong is it? A third party (your company) is indeed capable of monitoring the user's network activity in this scenario, correct? Seems like a pretty good feature to me, though I could maybe see altering the warning message in the case of certificates with properly set EKU or Name Constraints as being a good addition. – Ajedi32 Jan 3 '17 at 20:34

To answer your first question:

As far as I know, there is no way to circumvent this. It's a security feature.

To answer your second question:

Yes, non-default trusted root certs are definitely potentially problematic. They are often abused. They are sometimes used for workplace or traffic monitoring (which is potentially OK if adequately disclosed, though it may still feel sketchy to many), but they're also sometimes used by spyware, malicious apps written designed to snoop on your activity, and other icky stuff.

So, it's a tradeoff between (a) the risk of scaring users, when the user was already aware and nothing bad is going to happen, if you do show the warning, vs (b) the risk of users getting spied upon without their awareness, if you don't show the warning. The Android developers presumably had to make a judgement call on the relative severity and prevalence of these two risks, and presumably came down on the side of informing the user. I'm not in a position to form an independent view on this decision, but one can understand why they might have made this choice.

You linked to the issue on the Android bug tracker. Well, if you look at comment 8, you will see an explanation from an Android developer of why they chose this behavior. See also comment 39 for another scenario. So yes, there is a valid reason why they do this; whether you agree with their judgement or not, this is a public explanation of their reasoning.

| improve this answer | |
  • Just discovered that it has been reopened as #62644 .. I'll read it later today. So far I like this solution – goodguys_activate Jun 24 '14 at 13:04
  • 2
    I applaud the intent, but the implementation sucks. If I forward all my gmail to an external address, Google shows a notice I can't dismiss for a week and then shuts up about it. Something similar would be nice here. Show it long enough to guarantee the phone owner has seen it, but then accept that I really do trust my own CA (more than the public ones!) and in fact have increased my security by using it. Bah! – Basic Apr 3 '15 at 0:14

I find this "feature" to be quite boneheaded. The only people that would understand it are the technical users, who would also want to turn it off. Casual users will ignore it as soon as their technical support person tells them to, which adds yet another thing that the nontechnical user is clicking through and/or ignoring, thereby defeating the point of the obstinateness (sp?) of this "feature".

In searching for a solution, I found this Q&A, but I also found an app that moves the certs from userland to systemland. "Move Certs!" over on FDROID, courtesy of How To Geek.

| improve this answer | |
  • Lol you guys! I'm getting +1's and -1's at about the same rate for this, which is pretty funny. I think I've gotten 2 ups and 2 downs already. – YetAnotherRandomUser Jan 5 '17 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.