Over the last few days, several users let me know they were unable to download our apps from the Mac App Store. They reported that they were receiving this error message when trying to purchase or update:
App Store Error: Failed to verify the preflight file. It is not signed by Apple.
Emails like this are frustrating, because we have absolutely no official way to help such users—Apple handles everything related to the store after we submit our app. They test the app, hopefully approve the app, and then host it for downloading. If the app makes it through this process, it’s pretty clear the code itself is good, and any download issues are related to the user’s system.
In theory, Apple (in exchange for their 30% cut of our revenue) should be helping these users solve such problems. But based on what I’ve heard, that’s not usually the case, so they end up writing to me. After a bit of web searching, I found the cause and solution to the problem: Keychain Access.
In particular, the settings for OCSP and CRL in Keychain Access > Preferences > Certificates. For some apps, and for some users (but not for all apps, and not for all users; I don’t know why), these values must be set to “Best Attempt:”
If these two values are set to anything else, it’s possible that some apps and/or updates will fail to download with the above-noted error message. I’ve never personally touched those settings, and I was curious why others might; a friend pointed out this thread, which recommends changing the settings to reduce background bandwidth usage by the ocsp process.
In any event, if you’re having troubles downloading apps and updates—not just ours, but from any developer—from the App Store, check these settings in your Keychain Access app.
People might change those settings to mitigate the Heartbleed bug, and similar attacks that arise because browsers fail to completely check for certificate revocation. “Best attempt” means that if the certificate can’t be shown to be revoked, it is assumed to be valid. (Bad idea). This problem indicates that Apple still doesn’t have OCSP working properly throughout their software chain. It’s weird, but changing this setting in Keychain Access also affects how certificates are verified in the browser. (At least in Safari.) These settings, and the fact that they might cause problems with the Mac App store were discussed on the Security Now podcast, episodes 450, 452 & 453. e.g. transcript: https://www.grc.com/sn/sn-452.htm (search for “Keychain”)
Thanks for the further explanation!
-rob.
I have a better explanation. This occurs when you download an application from the App Store, and your Application folder already contains an application with the same name, but it doesn’t came from Apple. The solution is to delete the old copy before downloading the Apple version.
In your case, that means to delete the Usher demo downloaded from your web site before downloading the Apple version, as they both have the same name.
In my experience, the problem with having Usher Demo is *not* that it will cause errors … instead, the App Store version just won’t download, because it sees the app as already installed. But I’ve never seen (and I do a lot of dual downloading, obviously, to test our stuff) an error related to having duplicates — just a failure to download at all. (And sadly, Apple makes the failure silent, and you’ll just see Installed in the App Store. Of course, it’s not, it’s the demo version.)
But in general, yes, it’s always a good idea to delete any direct copies of any app if you’re trying to install the equivalent app from the App Store.
regards;
-rob.
Thank you, the Keychain Access solution just worked for me in updating an app that otherwise wouldn’t.