{"id":2941,"date":"2015-11-14T17:42:32","date_gmt":"2015-11-14T20:42:32","guid":{"rendered":"http:\/\/brockerhoff.net\/blog\/?p=2941"},"modified":"2015-11-20T11:48:54","modified_gmt":"2015-11-20T14:48:54","slug":"a-tale-of-two-certs","status":"publish","type":"post","link":"https:\/\/brockerhoff.net\/blog\/2015\/11\/14\/a-tale-of-two-certs\/","title":{"rendered":"A Tale of Two Certs"},"content":{"rendered":"

I’m keeping this post\u00a0updated<\/strong> as details develop…<\/p>\n

About ten days ago, something strange happened on my Mac: I was debugging the next version of my RB App Checker Lite<\/a>\u00a0app and suddenly I saw the dreaded dialog box:\"Damaged\"<\/p>\n

Completely abnormal, especially as I was debugging using the Developer ID version (not the Mac App Store version!) from inside Xcode. When I opened Terminal, the same dialog; when I opened Safari, same thing! No new process was allowed to run. Of course I had to reboot to be able to do anything, everything worked fine afterwards, and I couldn’t reproduce the problem, so…<\/p>\n

OK, a couple of days ago I concluded all was ready and I uploaded my app for review. A few hours after I announced so on Twitter, the reports<\/a> began appear: the sky is falling! Major Mac App Store meltdown, everybody was getting the \u201cdamaged\u201d dialog, Apple’s certificates were the culprit. I started testing my local apps from the MAS and, sure enough, the MAS leaf cert had expired; no problems, some of them asked anew for the AppleID password, some didn’t. RB App Checker Lite showed the expiration but no other problems, but I pulled it from review just in case.<\/p>\n

Two days of confusion and frantic coding later, I had submitted (and pulled!) 4 more builds until I was reasonably sure that everything\u00a0was working correctly. Thanks to several\u00a0fellow developers on Twitter, the upcoming version seems to show everything correctly; it turned out that my receipt checks were somewhat obsolete. I usually publish the direct download version only after the MAS version has passed review, but decided to release version 1.1.4, build 351\u00a0immediately: you can get it here<\/a>. It has a long list of improvements and fixes.<\/p>\n

Meanwhile, the consensus is that rebooting and re-entering the AppleID and passwords (or even deleting and reinstalling) the affected apps solves 99% of the problems.<\/p>\n

There are actually several different unfortunate problems here. First, the \u201cdamaged\u201d dialog seems to be caused by some sort of cache or memory corruption in the system processes that coordinate to implement GateKeeper and the app store updates; some reports say killing the \u201cstoreagentd\u201d process solves this problem without rebooting. (My system doesn’t seem to run this, FWIW.) What not everyone knows is that this dialog appears before the app it allowed to run; that is, it’s not affected by any checking done inside the app itself!<\/p>\n

Second, asking for a new AppleID password. This is caused by the app itself checking the store receipt; something strongly recommended by Apple, since otherwise, it’s easy to copy a downloaded app to another computer and having it run there; I remember some early games not doing this and being widely pirated.<\/p>\n

When an app is downloaded from the MAS, a proper receipt for that AppleID and that computer is already inside<\/em>. A missing or corrupted receipt is the\u00a0only<\/em> normal circumstance in which the \u201cdamaged\u201d dialog should appear. But if you copy the app to another computer, this will be noticed by the app itself.<\/p>\n

Once a MAS app starts up, the first thing it should do is to check\u00a0the receipt<\/a>. It’s a complex process and not everybody implements it the same way. At first, checking the receipt’s cert chain would cause the receipt to be rejected in the case of expiration; the app exits with a special numeric code (exit 173) and this code signals the system to put up the dialog asking to confirm the purchaser’s AppleID and password. This, in turn, will cause a new receipt to be downloaded, and the app can now run with no problems.\u00a0Update:<\/strong> reports indicate that, in at least some cases, the system doesn’t respond properly to exit 173.<\/p>\n

A few years ago receipts began to include a new field containing the receipt’s creation date, and developers now had to check the certs against that date (and not against the current date), therefore obviating the need to reenter the password. Unfortunately this was not widely divulged, and Apple’s own sample code hasn’t yet been updated accordingly; I confess to not seeing this myself!<\/p>\n

As is usual in disasters, several things have to go wrong at the same time: some bug corrupts a critical system cache, certificates expire normally, some apps incorrectly test for expiration, receipts are corrupted or the AppleID validation servers become\u00a0slow or unreachable (because of the huge number of simultaneous requests), and… boom.<\/p>\n

Many\u00a0articles, unfortunately, published factual errors or wrong assumptions.Let’s try to counter a few:<\/p>\n