[feedhenry-dev] Self Signed Certs in Android

[Vojtech Sazel]

Hi,

I think that MCP will be hosted on site like* openshift.io
<http://openshift.io>*. Doesn't they have simple some container that does
set up Letsencrypt <https://letsencrypt.org/> for the subdomain? However
it's necessary to have access to public internet for Letsencrypt.
I think that it would be ok to disable SSL certificate checks for debug
mode apps.

Vojtech

On Fri, Oct 6, 2017 at 4:14 PM, Julio Cesar Sanchez Hernandez <
jusanche at redhat.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>


-- 

VOJTĚCH SÁZEL

SENIOR QUALITY ENGINEER, MOBILE QE

Red Hat

<https://www.redhat.com/>

Remote Czech Republic

vsazel at redhat.com    IM: vsazel
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171006/943e8a7a/attachment.htm>