5

Ok, 4 hours burned, so I'm turning to SO in hope for help.

Here are the facts so you can understand quick:

  • We have an existing AIR Mobile app that runs fine on my laptop, and every Android device we've tested while in HTTP mode (Kindle, Nexus, Asus A100)

  • As soon as we switched to HTTPS, only the laptop and Kindle devices will connect to the server

  • On the other devices, I'm getting a FaultEvent returned, and the error says: "Send Failed. Channel.Connect.Failed error NetConnection.Call.Failed https://www.example.com/flex2gateway/cfamfsecure/"

  • I can hit the URL above on the Nexus/A100 in a browser and it returns a blank page just as expected

  • Flex-based apps using this same connection have been fine for years without problem - this is the first AIR app to use that HTTPS connection however

  • I'm using the Captive Runtime feature

  • ColdFusion 9 backend

  • I can't debug the web traffic because it only happens on the tablet, and I currently don't know how to capture traffic on a tablet, like I can on my laptop with Fidder (researching now)

I will provide any other info you need, and as quickly as possible - just let me know.

Other than the above, I've also looked at a few other things like: Ensure that the crossdomain.xml file exists and is setup properly, change the setting in CF's services-config.xml file, etc.

My current thought is that maybe it has something to do with chaining in the SSL Cert - like maybe the Root CA isn't trusted on the Nexus or something? (Which is GlobalSign Root CA) Or it has something to do with the default browser like in the Flex days and IE/proxies?

Never seen this before, so I'll take whatever help I can get.

[UPDATED]: I have created a small sample you can use to replicate this issue: https://www.dropbox.com/s/5nmilo3tbwr2k8d/HTTPTestSource.zip

It will contain everything you need: source, compiled .AIR (for desktop), compiled .APK (for android device). The Desktop works fine in HTTP and HTTPS, whereas the mobile APK only works for HTTP. I've also included a sample CFC to put on your own server if you want.

Thanks for reading this far!

ketan
  • 19,129
  • 42
  • 60
  • 98
PRB
  • 1,031
  • 11
  • 27
  • 1
    Does `adb logcat` print anything? – Alexander Farber Feb 20 '13 at 08:58
  • I will check and get back to you later today Alexander - on the road! By the way, I attempted to export the Certs from this website then import them into the tablet and it said they imported fine, but still did not work. – PRB Feb 20 '13 at 19:52
  • And once I turned off HTTPS, all tablets could connect fine (but I sorta need SSL) :) So I think I'm getting closer. – PRB Feb 20 '13 at 19:54
  • Ok so an interesting turn of events. When I tried to debug the app while on the hardware (so I could test out the logcat idea) the app worked. So here is another clue: DEBUG builds connect just fine, whereas RELEASE versions won't connect via HTTPS. Flex must be handling connections differently based on the debug option? Could this have anything to do with using a self-signed cert to build a release? So now when I run the debug version directly (not having FB run it) it brings up the "waiting for debugger" dialog, which I cancel, then the app connects to the server over HTTPS. Ideas? – PRB Feb 21 '13 at 01:24
  • 1
    Is it a self-signed cert? – Paul Gregoire Mar 01 '13 at 14:44
  • @Mondain: It's a self-signed cert on the *AIR* app, but the server cert is a purchased wildcard SSL cert. – PRB Mar 02 '13 at 20:12
  • Its been my experience that self-signed on the server wont work outside of debug mode. I have not tried a wildcard cert; but I have had luck using fqdn certs. – Paul Gregoire Mar 02 '13 at 20:17
  • Thanks @Mondain. Note that I uploaded a very simple sample (see link above) that shows the problem. Maybe it's something obvious that I am doing wrong? – PRB Mar 02 '13 at 21:20
  • Another point to make is that the Kindle Fire has the AIR runtime "baked in" from what I understand - ie: Which is why you can't install it from the store (which is why I'm using the captive runtime). Maybe that is why it works on a Kindle Fire and not others? – PRB Mar 02 '13 at 21:41
  • 2
    Holy mother of a targ. I think I found a solution. I tried re-compiling that WITHOUT captive runtime and installing it on a tablet that DOESN'T have a baked-in AIR runtime, and it WORKED. Hal-la-friggin-lu-ya. Now I just have to make sure it works with my real app, and I'll report back. – PRB Mar 02 '13 at 21:47
  • Nice! Glad to hear you solved it – Paul Gregoire Mar 03 '13 at 01:39

3 Answers3

4

[RESOLVED]

Well, I got it working for my situation - hope this helps for others.

The problem is the AIR Captive Runtime. It doesn't seem to work when using HTTPS. I had to switch to it because my first development hardware was a Kindle Fire, and the AIR Runtime is pre-installed on the Kindle Fire, but I needed the most recent version of AIR. So, I just turned on the Captive Runtime and went on my merry way.

When we went live, we changed the endpoint to our HTTPS server and the Kindles continued to work, where all other tablets failed.

To fix this, I turned OFF Captive Runtime and recompiled, and now after un/reinstalling it works on all my tablets, except the Kindle Fire, which I'll just have to provide a different install for.

Hopefully this helps others out there having the same problem.

PRB
  • 1,031
  • 11
  • 27
  • +1; although that sounds like a bug in the Captive Runtime code. Which version of AIR were you using? – JeffryHouser Mar 02 '13 at 23:50
  • 1
    Sorry, SO wouldn't let me enter comments all of a sudden, but today I can again. Ok, I was using what came with Flex 4.6 originally, which I believe was 3.1 if I remember right. I have now merged in AIR 3.5 and I'll see if that makes a difference. I could not get 3.6 to merge in and still compile. Thanks! – PRB Mar 12 '13 at 00:50
  • For future readers, see also @Gareth Arch's answer below; using newer versions of AIR with Flex will also fix this. – Brian Jul 14 '14 at 21:15
1

Thanks for the update to your question. It certainly helped me track down a solution to the problem. I installed AIR 3.7 along with the Flex 4.10 build from Apache Flex and was able to successfully connect to an https connection (using the Captive runtime after exporting a release build in Flash builder). So anyone running into this issue, should just use one of the newer AIR SDKs and it should solve it.

Gareth Arch
  • 86
  • 3
0

PRB,

I will preface this by saying that I am in no way shape or form a flex developer. I came across this information as I was recently researching a crossdomain.xml issue we were having here at work. I found a page on the adobe site that states there is an issue when calling a web service behind an HTTPS connection when the calling flex app is not behind an HTTPS connection as well.

You have to add a secure="false" attribute to the allow-access-from tag. 

<cross-domain-policy>
    <allow-access-from domain="*.mydomain.com" secure="false"/>
</cross-domain-policy>

I got this from http://livedocs.adobe.com/flex/3/html/help.html?content=security2_15.html.

There are some additional details in the comments section that might help also. You can call the WSDL over HTTPS but if the location fields in the WSDL have HTTP:// and not HTTPS:// then all of your remaining calls will be over HTTP and not HTTPS.

--

On a side note, it appears that the flash player and flex use the browser's http mechanism for transport, while AIR implements it directly, which could explain why your flex app is failing and the Air app is working. This might also be the issue as to why it works in debug (using the development environment http transport) and release (switching to the host browser http transport).

Tim Sapp

Tim Sapp
  • 86
  • 5
  • Thanks Tim! From what I understand/remember, the crossdomain.xml file doesn't apply to AIR apps, because they are not "in a domain". – PRB Mar 02 '13 at 20:08
  • Sorry, hit Enter and the comment sent. What I was going to say is that in the example above: there isn't really a "domain"...but I tried with "*" as well, to no avail. :( Thanks for your help though - any ideas help!!! – PRB Mar 02 '13 at 20:10