[feedhenry-dev] Self Signed Certs in Android

Julio Cesar Sanchez Hernandez jusanche at redhat.com
Fri Oct 6 14:14:31 UTC 2017

On Cordova Android apps, self signed certificates work in debug but fail to
connect in release.
On Cordova iOS and iOS native, self signed certificates don't work, even
configuring ATS to allow everything, self signed don't fall into the
"everything". There is some code you can add to allow connection despite
the self signed certificate, but it's not a good option. Apple might reject
the app if you forget to remove it before releasing the app.

On Fri, Oct 6, 2017 at 3:17 PM, Summers Pittman <supittma at redhat.com> wrote:

> While I'm testing out MCP and some of the client sdk sync refactoring I
> regularly get hit with Android not liking self signed certificates.*
> There are several work around for development such as
>  * setting up and maintaining a CA infrastructure and signing everything
> in correct fashion
>  * setting up DNS for developer to host their own domains and distribute
> well signed keys**
>  * injecting a SSL Handler that just doesn't check anything
> These are impractical, tedious and/or dangerous.  I will leave it as an
> exercise to the reader to decide which is which.
> However, for development scenarios we have the option of certificate
> pinning.  This is a fancy word for "If you see the certificate at this URL
> you are golden, ignore the haters".***  There are two general ways to pin,
> but they each have drawbacks.
> First, Android N has support for defining pins in your AndroidManifest.
> Android handles all of the dirty work for you, but this is only in Android
> N and above.  There do seem to be some attempts at back porting, but I
> haven't researched them too far,
> The second choice is for us to design our API layers such that pins can be
> injected and used by our underlying HTTP mechanisms.  Many frameworks
> already support pinning so it shouldn't be too hard to expose, but it will
> require more coordination and thought.
> So wdyt?  For the next couple of sprints we should be fine just using
> Android N's pinning, and eventually it will be the default solution.
> Also, I don't know how self-signed certificates run on cordova, windows,
> iOS, etc.  I wouldn't mind if those platforms' experts chime in.
> Summers
> * Java and thus Android won't by default make a connection if the
> certificate can't be authenticated both by a chain of trust and matching
> the domain the certificate claims to be for.
> ** This is kind of what fhcap does.  It works great fro Android
> development in an emulator but isn't practical for testing on devices as
> the DNS magic has to be set up on the device which fhcap can't control.
> *** I may have not used the correct technical jargon here.
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171006/7fe2e006/attachment.htm>

More information about the feedhenry-dev mailing list