I had a question when reading this article:

Phony certificates fool faulty crypto in apps from AIM, Chase, and more

(Basically, some Android apps, like Chase's banking app for example, may be ignoring certificate validation errors, possibly because the app is trying to accommodate outdated CA lists on older devices and Android versions.)

In the context of this sort of banking app, why wouldn't the developer use a private CA instead of signing the server (and, for that matter, client) certificates through one of the public CAs? The developer controls both ends of the transaction, after all. Am I missing something, beyond laziness?

  • 2
    Your queastion is predicated on the issue having been introduced deliberately - read the article again - particulalry The researchers attributed weaknesses to the "terrible design"...
    – symcbean
    Oct 25, 2012 at 15:26

3 Answers 3


The issues which are talked about in the article are mostly of the following kind: the applications misuse the protocol, in that they disregard validation errors. They do so because the application developers use SSL as a black box which is just assumed to "add security" by virtue of being there. These developers are not helped at all by the state of the documentation of many SSL libraries, which, when it exists at all, is rarely clear for anybody who has not studied X.509 certificate validation.

Someone who would use his own CA would be someone who is aware of the issue and understands what is going on when a certificate is used. That is the solution: that application designer would not make the mistakes to which the article alludes. A private CA is just the logical solution towards which application designers steer when they know what they are doing. Maintaining a private CA can be complex and expensive, but that's a symptom of certification being, generally speaking, a hard problem. The important point is that application designers must grasp what SSL and certificates do and do not. As long as they do not, no amount of private CA will save them.


Using a private CA wouldn't really change this. The bug is in the way that certificate validation is performed within the application code, which means that the application can be tricked into accepting fake certificates.

For example, you might buy a completely legitimate code signing certificate from any major CA, using the same name. For most standard certs, the CA won't verify the details. Since the device only does some primitive checks, it would accept that cert and allow you to perform a man-in-the-middle attack. Even if the vendor ran their own private CA, this would still be possible.

Take a look at some of the answers on this other question, which covers the vulnerabilities in detail.

  • 2
    I think what OP is trying to say is that it would be perfectly possible, if the bug wasn't there, to use a self-signed certificate for communication between app -> server. This way, one can configure the application to trust only that certificate, thus get trusted communication. Oct 25, 2012 at 13:17
  • 1
    Right, I should have been clearer in the question. The developers can set things up so that there is one and only one CA that is trusted, so the app is not dependent on the list of valid CAs that ship for a particular version of the OS (which may never get updated), which should remove any temptation to turn off the validation check. I'll try to clarify this in the question.
    – cjc
    Oct 25, 2012 at 13:21
  • In that case, as far as I can see it would be perfectly possible and advisable to do so. Huge CAs live by the mercy of web browsers, etc. trusting them, so don't tell them! Oct 25, 2012 at 13:34

The only real reason I could see beyond laziness, is the cost of maintaining a private CA/PKI infrastructure.

Doing that well (with good security) can be a pretty expensive proposition. Obviously doing it at a basic level (setting up keys, signing the certificates etc) is pretty easy, but then if you don't secure the CA keys well it could be pretty nasty if those get stolen (depending on what your app. does and how easy it would be to push an update).

You must log in to answer this question.

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