We have an Air app (SDK 4.5) which we are ready to deploy, but fails to connect via HTTPS URLs with error #2032 only on some Win7 computers but not others.
For troubleshooting, I can reproduce the problem using the simple test app example given in the AS3 URLLoader documentaton.
The issue is that when running the app on some Win7 boxes, trying to connect to various servers via https and download a simple document, the request fails with "Error #2032".
The Air runtime version is 3.0 and we updated to 3.1 with the same result. The problem is related to HTTPS only- the same URLs work fine with HTTP.
Now for the fun: the same exact air app works fine on other Win7 box's, XP box's, OSX 10.6 and OSX 10.7 pointing at the same HTTPS URL's.
More fun: on the Win7 boxes that fail, it only fails with some https URLs and not others, and the URLs that fail with this Air app on these certian win7 boxs work fine with the same air app on several other mentioned computers(XP, OSX and other win7).
I know that Error #2032 is a very generic "io error" and could be the result of many things, but in this case I have done some research to isolate what might be going on;
on the win7 boxes where the air app fails:
If we point the air app to a virtual host on our apache server setup with a self signed SSL cert, the air app pops up a panel saying the cert is not trused, and if we click "continue", we get the 2032 error and an http status code of 0. Apache never logs the request. This tells me that the air app is trying to negotiate an SSL session with the apache server, but never succeeds.
If we point the same air app to a virtual host on the same apache server setup with a REAL SSL cert, the air app never pops up the untrusted panel, but still fails with 2032 and http status code 0 returned.
If we point the same air app to a virtual host on the same apache server but HTTP instead of HTTPS, there is no failure and the request completes with a http status code 200.
Interestingly, If we point the same air app to various other HTTPS URLS on other hosts, both our servers and others on the internet that we know work, some fail the same way and some work fine.
NOW: If we run the same tests with this same air app, using the same HTTPS urls on other mentioned computers(XP, OSx and other win7), there is no failure and the request always completes just fine.
Another finding: you could theorize that there is something wrong with these win7 boxs, however the HTTPS URLs that fail with the air app, work fine on these boxes in IE and Chrome, also the same test app compiled as a Flex app and run in the browser on the machines that fail work fine with the same HTTPS URLs that fail with the air app, which to the air runtime having trouble on some win7 boxes.
This is a BIG problem for us, our Air app is a consumer app and will be deployed widely, and we can't have it failing to run only on certian computers and have no clue as to why.
Any help would be apprechiated.
PROBLEM SOLVED (mostly), however I am left with BiG worries over this.....
The problem was the time on the failing Win7 boxes were sigficantly off. Syncing them fixed the problem. I would suspect that others that have similar trouble check the time on the computers/servers.
This does beg the question as to why the AIR runtime cant negotiate an SSL connection under this condition, but every browser we tested on these same computers could?
I can buy that maybe the SSL protocol should by definition fail under these conditions, however for consumer use, where this cant be controlled, the implementation needs to be loosened up to allow it, and in fact all the commercial browsers can negotiate SSL connections under these conditions(time sync differences) - ecommerce would be in trouble if consumers cant reliably connect to a secure service via the internet just because the time is off on thier computer.
Can anyone in the Air group at Adobe address this concern about using AIR for consumer applications under this condition where you cant count on your app to install or run on who knows how many consumers computers? And to make matters worse, AIR doesent provide detailed diagnositc error information, so it is VERY time consuming or impossible to even troubleshoot a failue like this - in the field it would be rather impossible.