[feedhenry-dev] Self Signed Certs in Android

Mon Oct 9 10:27:46 UTC 2017

This is the code needed

@implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
    return YES;
}
@end

Other option is to tell the users to install the certificate on the device
and trust it.

I'm +1 on using HTTP in development mode if possible

On Mon, Oct 9, 2017 at 12:12 PM, John Frizelle <jfrizell at redhat.com> wrote:

> This is going to be a challenge - not just for us, but for others who try
> to run our software locally, so we should invest some time and headspace in
> figuring it out.
>
> @Summers - Re: "The second choice is for us to design our API layers such
> that pins can be injected and used by our underlying HTTP mechanisms" - Can
> you provide some more information here - it seems like the most robust
> option from what you have outlined.
>
> @Julio - Re: "There is some code you can add to allow connection despite
> the self signed certificate, but it's not a good option." - Can you provide
> some more information here please.
>
> What are the options for running with just HTTP in development mode - in
> terms of OpenShift, Android and iOS? I know that apple were planning to
> mandate everything over https but have pulled back from it a bit...
>
>
>
>
> --
> John Frizelle
> Chief Architect, Red Hat Mobile
> Consulting Engineer
>
> mobile: *+353 87 290 1644 <//+353872901644>*
> twitter:* @johnfriz*
> skype: *john_frizelle*
> mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>
>
>
>
> On 6 October 2017 at 17:15, Vojtech Sazel <vsazel at redhat.com> wrote:
>
>> 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>
>>
>> _______________________________________________
>> 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/20171009/7cc28354/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171009/7cc28354/attachment.png>