Trouble with o.t.a. distribution from a secure server

[Umanoff]

I've been successfully deploying, over-the-air, an iOS app that I developed for a client. I'm using my client's own Enterprise Developer credentials.

I've been doing tests from my own http server, housing all of the requisite files there (.plist, .ipa, and of course the html page that carries the download link); and also from a combination of servers: a secure one holding the html, re-directing to another, un-secure, server holding the .plist and .ipa.   All's well with all of this.

But I run into trouble when I move everything to a secure server. There, the html opens properly, but on attempt to download (by tapping on the same link that works on my un-secure server), I get a "Cannot connect to <server name>"

I've changed the URL in both the html and .plist to reflect the new actual https:// address at the secure site. The site certificate seems to be valid and recognized. Another tester has also had the same problem when trying this for me.

Does anyone have any idea what this might be about?  Should the manifest .plist be carrying any certificate info?

[Colin Holgate]

With iOS 7.1 you have to do OTA from a secure server, but also the certificate has to be real. I don’t think that self assigned certificates work. At least they don’t from our server.

The only options are to either use one of the many services for creating a real certificate, or just do your testing from an HTTP server to iOS 7.0 devices.

If you want to drag the IPA on to an iOS 7.1 device, you can do that, but it would need to be by using Xcode 5.1, and not 5.0.

I’ve been pestering our IT guy to fix the certificate on our server. If he gets around to it, and it fixes the issue, I’ll let you know.

[Umanoff]

Thank you Colin, but my problem is NOT iOS 7-specific. And our server's certificate is valid and recognized.

[Colin Holgate]

How are you building your files? I use this Mac app:

https://itunes.apple.com/us/app/betabuilder-for-ios-apps/id415348946?mt=12

I just drag the IPA on to that app, type in the final URL for the files, and it builds all the files needed. I usually have the server mounted on my desktop, so I can build the files straight into the right folder. Sometimes though that can lead to permissions issues, and I have to repair those. A way around the permissions issues is to build to a local folder and then FTP up to the server folder. I think that works with less risk of messing up the permissions.

After the first time with any given app I can then just pick it from the Recent menu, no need to even drag the IPA file onto Beta Builder.

[Umanoff]

Colin, just to be clear before I try your suggestion: are you having success with o.t.a. downloads from secure servers (i.e.with the .ipa on a https:// server) ?   If so, with which iOS versions?

[Colin Holgate]

No, because iOS 7 doesn’t like our server certificate. I’m still trying to get our IT person to replace the certificate with a certified authority one, to see if that helps.

My work around for now is to use HTTP://. iOS 7.1 still won’t work, because it demands HTTPS://, but at least iOS 6 and 7.0 users can install the apps, even with the shady certificate.

[Umanoff]

Colin, I did some tests with 7.1 today and here's what I found:

With iOS 7.1, html and manifest.plist files MUST be on a secure server. The .ipa MUST NOT be on a secure server for the download to work!

This, to me, is buggish behavior and I'm hoping to get some clarity from Apple in the next few days.

If you can get different results with the .ipa on https, please post here.

[User_Unknow]

i use dropbox for https install 🙂

create folder and 3 files - html, plist and ipa

create shared link for each file and change https://dropbox.com to https://dl.dropboxusercontent.com inside html to plist and inside plist to ipa

this is legal freeware and working solution. just update your files - shared links will be the same after file updating 🙂 work successful with 7.1

[Umanoff]

Thank you Anton. But why should this not work on a private https server?

[User_Unknow]

I dont said that 🙂 I just mentioned that u can use dropbox if dont have own https

[Umanoff]

I know that you didn't say that. I ASKED that! 😉

[Colin Holgate]

I still think there may be a certificate issue, and dropbox most likely are using good certificates.

[Umanoff]

Colin, thanks but it can't be THAT hard to have a good certificate. And a bad certificate is immediately noted, in any event, by good browsers. Anyway the certificates on the servers I'm playing with are quite good.

I'm now investigating a MIME-type issue on various server types.

[Umanoff]

This turns out to be an easy, but hard to find, solution. If the .ipa is served by Microsoft's IIS server software v6.0 or later, the MIME-type settings must include .ipa as 'application/octet-stream'. Otherwise no file is served. Safari on iOS then just gives a dumb 'Cannot download ..." message.  Apache servers are a little smarter -- they'll deliver in any event.

So this is not really a http - https issue. I was fooled because my https attempts were all happening from IIS servers that weren't set up properly. It's also not a certificate issue, or either really a iOS 7.1 issue. I guess it works from Dropbox because they run Apache or a properly MIME-typed IIS server.

[Colin Holgate]

Thanks for reporting back. I guess our server already had the MIME issues sorted out, I only had to user the right certificate.

[Umanoff]

I've traced the prob down to this: if the .ipa sits on a secure server then the download fails. Doesn't matter where the .plist or html files sit: secure or unsecure. Still looking for ideas about this.