Beware Apple Security Certificates After October 24
If you have macOS or other Apple installers, chances are that they’ll be signed, or use as an intermediate certificate authority, by a certificate which expires very shortly. If you were to try installing that package, macOS will report that it’s damaged, and can’t be used. The installers affected can be very recent: I’ve checked an Installer package for the Mojave 10.14.6 Supplemental Update 2, which shipped on 23 September, just a month from the date of expiration, and both its intermediate and user certificates expire on 24 October 2019.
[…]
This is unfortunate timing, as it’s when those migrating to Catalina are likely to be downloading Mojave installers to give them a safe way back if necessary, or to use in a VM provided by Parallels Desktop or VMWare, for instance. In a week or two you could discover that those installers can no longer run because of this expiration. The only real solution is to wait until after 24 October, then download all important Apple installers, which should have new certificates.
Previously:
- Catalina “softwareupdate” Can Download Old Installers
- Installing Old Versions of macOS
- More Mac App Store Certificate Problems
- No One Minding the Store
Update (2019-10-31): Howard Oakley:
As usual, Apple isn’t saying anything, not to users or developers. Its most meaningful communication about this inexcusable failure of support were the 404 errors from download pages. There’s no explanation, no apology, no timescale, no support. Yet again, it seems to hope that if it pretends nothing has happened, we’ll all forget about it. Just like Apple clearly did until someone’s Calendar notified them that crucial certificates expired in a few days time.
As a follow-up to last week’s expiration of the certificate used to sign previously-released macOS installers, Apple has released re-signed macOS installers with the new certificate which is good until April 2029.
Update (2019-11-01): There are reports that this same issue is responsible for HomePods getting bricked.
Update (2019-11-05): Felix Schwarz:
Following issues with expired #macOS installers, Apple now provides direct download (!) copies of updated installers for macOS 10.10 - 10.12. For macOS 10.13 - 10.15, Apple provides App Store links.
See also: TidBITS.
4 Comments RSS · Twitter
@VS I think the issue is that Apple doesn’t use the timestamps when verifying. See, for example, the old post I linked above where you have to set the clock of your Mac back to use an old installer.
@VS
Michael and Howard have it right. I am not sure why Apple signs their installers this way, but I got hit years ago. I mean, like more than 5 years ago, maybe 8? I cannot remember exactly. I can tell you that I had a ton of installers downloaded and not a single one was valid. I had to redownload everything or set my clock back.
I used to keep copies of installers locally because it made reinstallation easier. I do agree the issue seems avoidable, but "courage".
Today is November 23, 2020. Two days ago I upgraded a client's Yosemite system to High Sierra using a freshly downloaded Installer. Now every App Store app refuses to lunch with a codesigning error. Apparently this is a long running problem. Is there any way around it?
Like Nathan, years ago I was in the habit of keeping a ton of installers downloaded for convenience, but when Apple started putting expiration dates on them I gave up doing that. Now the fresh ones don't work either. WTF?
That article is written as if timestamping didn't exist and this was unavoidable -- but that doesn't make any sense. Signing executables with cryptographic timestamps is done precisely for this reason: even after some of the certificates in the chain expire, signatures can still be validated w.r.t. the point in time when signing took place. And Apple's signing tools use it by default.
So the interesting question is: does Apple not use timestamps on their own packages, or is the mass resigning just good-hygiene maintenance?