I'm trying to install the iOS application via Safari.
When archiving the IPA file I have checked in Over Air installation and entered the right URL for ipa, 57x57, 512x512 images. Then created Manifest Plist file.
And I'm calling the Manifest file using the below URL
itms-services://?action=download-manifest&url=MANIFEST_SERVER_URL
While trying to open the link, It shows Open in iTunes correctly, but nothing happens for some time.
Then I get this alert "Cannot connect to URL".
Why is this happening? Is this because we are using self signed certificate in our server. If yes how to resolve it without buying the certificate.
You need a valid HTTPS cert to use this.
You can
get a free cert at letsencrypt.org
upload your app to DropBox or other file sharing service that provides an HTTPS URL
distribute build via distribution service like hockeyapp or TestFlight
I had the same issue on iOS 11 with a self-signed certificate. But it works fine on iOS 13.
After searching around, I finally got a workaround:
Go to Settings > General > About > Certificate Trust Settings. Under "Enable full trust for root certificates", turn on trust for the certificate.
Official document
I have gone through dozens of articles, stackoverflow questions and sites, my only requirement is to send .ipa file through url where client could check it in safari and install.
does not want third party installation, I've got my own server
my server is not having ssl that means it can be sent only http not https. please dont ask me to have ssl.
could able to install in any ios device, udid is not added to enterprise certificate.
My problem is when I am keeping these 3 file that are a) index.html. b)manifest.plist. and c).ipa file in server and trying to install in device, I am getting an pop up message saying that "certificate is not valid." Please help.
Hope the link below helps you out.
http://readwrite.com/2010/12/16/apple-best-kept-secret-how-to-do-ad-hoc-installs
But i dont think Apple allows you to distribute using http. Https is a mandatory for the URL that the user uses to download. So until you get a https i dont see that issue being solved
Your own server should be fine. As long as your .plist and .ipa are both accessible on the network to which the iPhone is connected.
Unfortunately, starting with iOS 7.1, app installs must be accessible over SSL (https).
The only way to do this is with an enterprise distribution profile. You will need to have an enterprise account to do this, which will require a company's EIN. So you can't do this as an individual developer. (https://developer.apple.com/programs/enterprise/)
You are seeing the error because of the lack of a valid SSL certificate on your server. iOS is swapping your http:// link in your plist with https:// (see this post: https://stackoverflow.com/a/20276908/3708242), which as you said does not have ssl enabled.
Bottom line, you'll need to get a server with SSL to host the files. Also, if you don't want / can't manage the UDIDs for the devices, you will need to get yourself an enterprise account so you can create an enterprise distribution profile to use to build your app.
There are online tools that simplify this process of sharing, for example https://abbashare.com or https://diawi.com
Create an ipa file from xcode with adhoc or inhouse profile, and upload this file on these site.
I prefer abbashare because save file on your dropbox and you can delete it whenever you want
Is there a concise guide to signing and distributing apps over the air for iOS? We have an extremely simple app to be distributed in-house to five or six users. Not going to get a $10000 MDM solution.
Apple's documentation is absolutely incomprehensible.
Sorry, been futzing with this for two days.
We have an iOS app. I can install it on my phone for debugging using xcode. Runs perfectly.
We loaded the plist, ipa, and icons onto an IIS server. The IIS Server is secured using an SSL cert. You have to log in, and then click on a link to be taken to the page with the download link. So even getting to the link means you have authenticated.
All the links in the plist file are https links.
I can manually type the https address for the plist file and I get an XML file in Chrome or Safari from my PC, my Mac, or my iPhone.
If a person hits the link on an iPhone, "cannot connect to server www.example.com". In the iPhone console, I see the error message SSErrorDomain Code=2 cannot log into iTunes.
Driving me crazy. As best as I can tell, the itms prefix is not using the https link, but how to tell?
For in-house distribution (outside the App Store), you need to have an enterprise developer account, and sign the app with an Ad Hoc Provisioning profile.
If you don't have an enterprise account, you'll have to specify a list of devices when creating the provisioning profile (not recommended).
You could then host the app on a web server, and have the users download it through Safari.
Got it to work. Praise the Lord.
I moved the ~/app directory from a server that required authentication to one that does not but only holds the app and nothing else. The server is secured by a SSL certificate issued by GoDaddy so it's not self signed.
I think that Apple was trying to come back to the site somehow to check something and the authentication/redirection was blowing that up.
I also edited the plist and index.html files manually removing all white space (tabs & spaces) which had been inserted.
Gonna test it on a wider audience now.
We distribute apps via an Enterprise account, using an itms-services:// URL. This has always worked fine, but after installing the iOS 7.1 beta on our iPad it refuses to install. Instead we just get the generic Cannot connect to example.com message that iOS unhelpfully displays when there is any sort of problem downloading the app.
I've been unable to find anything here on SO, on Google or in the 7.1 release notes to suggest what could be causing the problem.
I found the issue by connecting the iPad to the computer and viewing the console through the XCode Organizer while trying to install the app. The error turns out to be:
Could not load non-https manifest URL: http://example.com/manifest.plist
Turns out that in iOS 7.1, the URL for the manifest.plist file has to be HTTPS, where we were using HTTP. Changing the URL to HTTPS resolved the problem.
I.e.
itms-services://?action=download-manifest&url=http://example.com/manifest.plist
becomes
itms-services://?action=download-manifest&url=https://example.com/manifest.plist
I would assume you have to have a valid SSL certificate for the domain in question. We already did but I'd imagine you'll have issues without it.
ingconti is right.
Upload your app.plist to dropbox.
Get shared link of app.plist, like https://www.dropbox.com/s/qgknrfngaxazm38/app.plist
replace www.dropbox.com with dl.dropboxusercontent.com in the link, like https://dl.dropboxusercontent.com/s/qgknrfngaxazm38/app.plist
Remove any parameters on the dropbox shareable link such as "?dl=0t" (as per Carlos Aguirre Tradeco at Enterprise app deployment doesn't work on iOS 7.1 and my own experience).
Create a download.html file with a link formatted as INSTALL!!
Upload your download.html to dropbox
Again, get a shared link of download.html, like https://www.dropbox.com/s/gnoctp7n9g0l3hx/download.html, and remove any parameters.
Replace www.dropbox.com with dl.dropboxusercontent.com in the second link as well, like https://dl.dropboxusercontent.com/s/gnoctp7n9g0l3hx/download.html
Now, visit https://dl.dropboxusercontent.com/s/gnoctp7n9g0l3hx/download.html in your device, you can install the app like before.
WHAT A WONDERFUL WORLD！
Further to the Mark Parnell's answer, a quick-and-dirty way of getting around this is to put the manifest plist into Dropbox, and then using the Dropbox web interface to get a direct https link to it ('Share link' -> 'Get link' -> 'Download').
The actual ipa can remain wherever you always served it from. You'll need to URL-encode the plist's URL before inserting it into the itms-servivces URL's query (although just replacing any &s with %3D might work).
One downside is that the install dialog will now read "dl.dropbox.com wants to install [whatever]".
It is true, going forward you are expected to do all OTA deployments over https going forward with iOS7.1. Shame on Apple for not documenting this.
For those of you that are looking for a better in-house solution than relying on dropbox or having to fork out cash for a certificate you can have a solution if you follow the steps outlined in tip #5 here: http://blog.httpwatch.com/2013/12/12/five-tips-for-using-self-signed-ssl-certificates-with-ios/
The gist of it is this:
Create your own CA Authority certificate that you can install on the device that is fully trusted (I installed by simply emailing it)
Create the key/cer pair against the root certificate and install it on your server
Make sure your webserver utilizes the key/cer pair that matches the CA Authority root certificate
At this point you should be able to install your apps as usual over https
All of this can be accomplished on OSX using openssl which is already installed by default
This is not the same as just doing a self-signed certificate, in this solution you are also acting as your own private Certificate Authority. If your root certificate that is installed on your Apple device is not marked as Trusted (green) then something is wrong. Do it over.
This absolutely works.
Update: 3/13/2014 - I have provided a small command line utility that simplifies this entire process. You can get it at: https://github.com/deckarep/EasyCert/releases
I had the same problem and although I was already using an SSL server, simply changing the links to https wasn't working as there was an underlying problem.
Click here for image
That highlighted bit told me that we should be given the option to trust the certificate, but since this is the app store, working through Safari that recovery suggestion just isn't presented.
I wasn't happy with the existing solutions because:
Some options require dependance on a third party (Dropbox)
We weren't willing to pay for an SSL certificate
Free SSL certificates are only a temporary solution.
I finally found a solution by creating a Self Signed Root Certificate Authority and generating our server's SSL certificate using this.
I used Keychain Access and OSX Server, but there are other valid solutions to each step
Creating a Certificate Authority
From what I gather, certificate authorities are used to verify that certificates are genuine. Since we're about to create one ourselves, it's not exactly secure, but it means that you can trust all certificates from a given authority. A list of these authorities is usually included by default in your browsers as these are actually trusted. (GeoTrust Global CA, Verisign etc)
Open Keychain and use the certificate assistant to create an authority
Fill in your Certificate Authority Information
I don't know if it's necessary, but I made the authority trusted.
Generating a Certificate Signing Request
In our case, certificate signing requests are generated by the server admin. Simply it's a file that asks "Can I have a certificate with this information for my site please".
Next you'll have to create your Certificate Signing Request (I used OSX Server's Certificates manager for this bit
Fill in your certificate information (Must contain only ascii chars!, thanks #Jasper Blues)
Save the generate CSR somewhere
Creating the Certificate
Acting as the certificate authority again, it's up to you to decide if the person who sent you the CSR is genuine and they're not pretending to be somebody else. Real authorities have their own ways of doing this, but since you are hopefully quite sure that you are you, your verification should be quite certain :)
Go back to Keychain Access and open the "Create A Certificate.." option as shown
Drag in your saved CSR to the box indicated
Click the "Let me override defaults for this request button"
I like to increase the validity period.
For some reason, we have to fill in some information again
Click continue on this screen
MAKE SURE YOU CLICK SSL SERVER AUTHENTICATION, this one caused me some headaches.
You can click continue through the rest of the options.
The Mail app will open giving you the chance to send the certificate. Instead of emailing, right click it and save it.
Installing the Certificate
We now need to set up the server to use the certificate we just created for it's SSL traffic.
If the device your working on is your server, you might find the certificate is already installed.
If not though, double click the Pending certificate and drag the PEM file that we just saved from the email into the space indicated. (Alternatively, you can export your PEM from keychain if you didn't save it.)
Update your server to use this new certificate. If you find that the new certificate won't "stick" and keeps reverting, go back to the bit in BOLD ITALIC CAPS
Setting Up Devices
Each device you need to install apps on will need to have a copy of this certificate authority so that they know they can trust SSL certificates from that authority
Go back to Keychain Access and export your certificate authority as a .cer
I then put this file on my server with my OTA apps, users can click this link and download the authority certificate. Emailing the certificate directly to users is also a valid option.
Install the certificate on your device.
Test
Make sure your plist links are https
Try and install an app! It should now work. The certificate authority is trusted and the SSL certificate came from that authority.
I can confirm it works, But You have to put html AND plist on dropbox.
It works also for non-enterprise OTA, i.e. You want to share app with your dev. team.
I did:
a) on my site I made a page with this link:
..
href="https://dl.dropboxusercontent.com/u//(your DB id)/ipa.html">MyApp
b) on DropBox I wrote another HTML page:
.. https://dl.dropboxusercontent.com/u/(your DB id)/MyApp.plist">
Tap to Install MyApp
c) moved plist on DropBox but leaving it to POINT to my old server (no https)
Open up terminal and run the command:
curl -i https:// (.ipa file path not plist)
This will tell you whether or not the installer can see the IPA file. If you run the curl command with the '-i' you'll see the full response and it's probably not the IPA file.
This is the response the installer sees, so if it's not returning HTTP 200 and an IPA you'll need to return it on your end.
The ITMS installer doesn't save any context from Safari. If you authenticated into a secure portal in Safari, the authentication cookies aren't pass to the the installer. i.e. The installer needs to be able to see the app without authentication and this could be the reason you are getting 'Cannot connect to server'.
I had same trouble and did as mentioned above.
Put the plist in dropbox.
Over the download file button, below an image of the document with mouse right button select the copy link action. This link is already something like
https://dl.dropboxusercontent.com/s/xyz123/app.plist?stuff=stuff
with many params.
Remove the parameters (kept only address between https and .plist)
Browse for url encode online, selected one of those links, copy, paste, execute, then the resulting text copied and pasted into the html where I have the itms-services link.
By the way I have this html in two different locations, one of those is where the ipa is located.
Make sure the plist includes absolute references to the ipa file.
Both pages worked successfully for installing the app in iphones with ios 7.1
But, now iphones with ios 7.0x can't install the app.
I created a new question: upgraded adhoc app deployment doesnt work on ios previous to 7.1
Both issues are tightly related, and also bonded by the lack of official references.
Some nice guy handled the issue by using the Class 1 StartSSL certificate and shared Apache config that adds certificate support (will work with any certificate) and code for changing links in existing *.plist files automatically. Too long to copy, so here is the link:
http://cases.azoft.com/how-to-fix-certificate-is-not-valid-error-on-ios-7/
If you happen to have AWS S3 that works like a charm also. Well. Relatively speaking :-)
Create a bucket for your ad hocs in AWS, add an index file (it can just be a blank index.html file) then using a client that can connect to S3 like CyberDuck or Coda (I used Coda - where you'd select Add Site to get a connection window) then set the connections like the attached:
Then build your enterprise ad hoc in XCode and make sure you use https://s3.amazonaws.com/your-bucket-name/your-ad-hoc-folder/your-app.ipa as the Application URL, and upload it to your new S3 bucket directory.
Your itms link should match, i.e. itms-services://?action=download-manifest&url=https://s3.amazonaws.com/your-bucket-name/your-ad-hoc-folder/your-app.plist
And voilá.
This is only for generic AWS URLs - I haven't tried with custom URLs on AWS so you might have to do a few things differently.
I was determined to try to make James Webster's solution above work, but I couldn't get it to work with Plesk.
As an alternative to using Dropbox for enterprise distribution you can use TestFlight for the distribution of enterprise signed apps.
https://www.testflightapp.com/
This is a fantastic service for the hosting and distribution of both ad-hoc development builds AND enterprise builds.
Further the previous answers about Dropbox, I implemented the following files tree such as only the PLIST file has to be uploaded to Dropbox:
upload the ipa file to your server in http (no change here)
upload the provisioning (.mobileprovision) file to your server in http (no change here)
upload the plist file to your dropbox (no change to do inside the plist file as the URLs are in absolute)
use the option "Share the link with Dropbox" which copies the link to your clipboard. This link has to be copied into your html file into the itms-servivces URL's query after changing the part www.dropbox.com by dl.dropboxusercontent.com. Note I URL encoded the link as suggested by #Mike but I don't test without to do it. Now the itms-services URL's query should look like this: itms-services://?action=download-manifest&url=https%3A%2F%2Fdl.dropboxusercontent.com%2Fs%2FYourShortDropboxLink.plist
upload the html file to your server in http. Note the html file contains both links to ipa and provisioning files.
access to your html file from your device and now the ipa can be installed by OTA like usually.
From now, only the ipa file has to be changed to provide next app versions by OTA to your beta testers. Until Apple is yet changing the security rules.
I join here after the very simple HTML file I'm using:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>iPhone app for test</title>
</head>
<body>
<h1>iPhone app for test</h1>
<br/>
<ul>
<li><a href="http://www.yourdomain.com/with/directories/provision/v.last/yourprovision_adhoc.mobileprovision">
Install Provisioning File</a></li>
<li><a href="itms-services://?action=download-manifest&url=https%3A%2F%2Fdl.dropboxusercontent.com%2Fs%2FYourShortDropboxLink.plist">
Install Application</a></li>
</ul>
</body>
</html>
Our team uses dropbox for ad-hoc distribution which uses https but still our app was failing to install. After much trouble-shooting we realized that the title field is required too. Whenever we sent out a link without this field safari ignored the link and did not prompt the user to install. Sometimes for quick development tests we skipped over the title node in the xml and not populate it. In case this is helpful for anyone having this issue make sure that your .plist contains the following nodes populated:
....
<string>software</string>
<key>title</key>
<string>Your App Name</string>
...
After reading this post I had still a problem with downloading my app. Problem was because of self signed SSL certificate.
I've found a solution for this problem. You need to upload your certificate file with extension '.crt' on the web and type address of it in your mobile safari. System ask you about adding your certificate to the list of trusted certificates. After this operation you will be able to install your ad-hoc app.
The universal solution is to connect your device to Mac and to observe what's going on during installation. I got an error:
Could not load download manifest with underlying error: Error
Domain=NSURLErrorDomain Code=-1202 "Cannot connect to the Store"
UserInfo=0x146635d0 {NSLocalizedDescription=Cannot connect to the
Store, NSLocalizedRecoverySuggestion=Would you like to connect to the
server anyway?, NSLocalizedFailureReason=A secure connection could not
be established. Please check your Date & Time settings.,
NSErrorFailingURLStringKey=https://myserver.com/app/manifest.plist,
NSUnderlyingError=0x14678880 "The certificate for this server is
invalid. You might be connecting to a server that is pretending to be
“myserver.com” which could put your confidential information at
risk.", NSURLErrorFailingURLPeerTrustErrorKey=,
NSErrorFailingURLKey=https://myserver.com/app/manifest.plist}
There was even the suggestion in that error to check date settings. For some reason the date was 1 January 1970. Setting correct date solved the problem.
Apter tried to change itms-services://?action=download-manifest&url=http://.... to itms-services://?action=download-manifest&url=https://..... It also cannot worked. The alert is cannot connect to my domain. I find out that also need update the webpage too.
The issue isn’t with the main URL being HTTPS but some of the HTML code in a link within the page. You’ll need your developers to update the webpage. I also noticed there isn’t a valid SSL certificate on your staging domain so you’ll need to get one installed or use Dropbox and here is the link maybe helpful for you
My company recently joined iOS enterprise program to distribute in-house app to our employees. We choose over-the-air installation for our app and put the .plist and .ipa file inside our web server which are protected by our Id/password mechanism. It's means that you must log into our web site first then you can install the app. The whole process works fine when we put these files in open area(not protected by ID\password). However, once we put files behind protected it's showed "can not connect to example.com " and Xcode’s device console view shows
“Jul 21 11:17:39 unknown itunesstored[385] : Could not load
download manifest with underlying error: Error Domain=SSErrorDomain
Code=2 "can not connect to iTunes Store" UserInfo=0x1c551fb0
{NSLocalizedDescription= can not connect to iTunes Store}”.
I guess it’s because the session it’s not the same when we open the itms-services://… link which iOS called the process to install the app.
The iOS installer is a sandboxed process that will only make an itms-services request. There is absolutely no way of forcing the installer to authenticate to your backend server. You will need to make your plist an unprotected resource or roll your own authentication mechanism based on values in the url. Also, you can't use self-signed certificates to SSL protect your plist.