Check Packages for Expired Certificates in Mac OS X
Many Mac users will download package files of combo updates or other software in order to install them on multiple computers, thereby avoiding updating with the Mac App Store. This is particularly common with Mac systems administrators, where it makes more sense to download a single package update or installer once and distribute it over a network or perhaps install manually through a USB drive. There is nothing wrong with this approach at all, and in fact it’s much more efficient for multi-Mac management, but one potential hiccup arrives when a package installer or update file has an expired certificate, which will prevent the package from installing entirely, a situation that becomes obvious when you get an “(application installer) was signed with a certificate that has expired” error message.
To avoid this situation, you can check package signatures yourself to see if they are valid, if they have expired, or even if they have no signature at all.
How to Check Package Signature Status in Mac OS X with pkgutil
The excellent pkgutil command line utility can easily determine the status of any package signature and certificate. It’s easy to use, so launch the Terminal app from /Applications/Utilities/ and try it out yourself.
The basic syntax to use for checking a package signature status is like so:
pkgutil --check-signature /Path/to/Example.pkg
Hit return and you’ll find out if the signature is valid, if the signature has expired, or if there is no signature at all.
For example, let’s say we have an Mac OS X Combo Update software installer package, a common scenario for sysadmins updating multiple Macs, you could check the status of that packages signature like so:
pkgutil --check-signature ~/Downloads/OSXUpdateCombo10.10.2.pkg
Package "OSXUpdateCombo10.10.2.pkg":
Status: signed by a certificate that has since expired
In this case, the signature for the update package has expired, meaning it will throw an error if usage is attempted.
Not all package installers have signatures however, and while any software update file from Apple will, packages from third parties often do not. For example, this example package installer file has no signature, and should be treated appropriately (i.e. if you don’t trust the source, perhaps reconsider using it).
pkgutil --check-signature ~/Downloads/MysterySketchyInstaller-21.pkg
Package "MysterySketchyInstaller-21.pkg":
Status: no signature
If a package file is dubious, you can verify the code signature and extract the package without installing it with pkgutil to give it a further inspection, or if you prefer to use the GUI then an app like Pacifist offers similar package management tools in a friendlier interface, even if it’s still on the advanced side of things.
Like all good command line tools, you can even feed pkgutil wildcards to easily check multiple packages at the same time, in this example we’ll check the signature of every *.pkg file contained within ~/Downloads:
pkgutil --check-signature ~/Downloads/*.pkg
Package "irssi-0.8.17-0.pkg":
Status: no signature
Package "wget-4.8.22-0.pkg":
Status: no signature
Package "ComboUpdateOSXElCapitan.pkg":
Status: signed by a certificate that has since expired
Package "InstallOSXSequoiaBeta.pkg":
Status: valid
Package "HRFDeveloperTools.pkg":
Status: valid
Wildcards will make quick work of checking certificate status of many different package files, just be sure you specify *.pkg for the process to complete without stopping on a file that is not a recognized package.
> InstallOSXSequoiaBeta.pkg
Was it ever actually called that? When would this package have appeared?
Very Useful for me thank u for your valuable information
wild card expansion doesn’t work for me either — not sure why. had to do a basic for loop
cd /Volumes/OS\ X\ Install\ ESD/Packages; for PACK in $(ls |grep pkg); do pkgutil –check-signature ./$PACK;done
I find it annoying that they expire. As a developer, I really don’t see the point. Once signed, the app and installer should always be good. Another one of Apple’s quirks.
I agree completely, particularly since the expiration of certificates lead to the Mac apps (and even OS X installer) not working at all! Apple behaves like a 5 year old company run by kids sometimes, yet they are 40 years old and the richest company in the world. Of course, they spend their big money on share buybacks to juice returns rather than software development efforts apparently. Maybe they could afford a few software engineers to work on this problem? Should I buy another 10 iPhone 7s to contribute?
I agree with Joe. I work at a school in the graphics dept. We sometimes need to install the older OS for various reasons (use obscure software to access archived files). I have a fine collection of USB stick installers…and they no longer work. I have heard that you can temporarily change the system date and time of the computer to more nearly match the certificate date and use the installers, but I have not had the opportunity to test that.
Yes that is correct, you can fix the errors with the installers by setting the date back. Aim basically for the date of which the software originated, but generally anytime before 2015 works since this is when they really started screwing the pooch on certificates.
The date trick works to install the software, but that is besides the point. This should not happen, but Apple has screwed up certificates and let them expire multiple times, which suggests to me they really don’t care that much. They force the App Store and certificates and all of this on devs and users, then they don’t even maintain it properly. Hard to believe. Does Phil Schiller care? Does Craig Federighi care? I can tell by Eddy Cue running iTunes and his shirt choice on stage presenting he doesn’t care either.
How many I.T. departments will look to redeploy BACK to Windows if this behavior continues?
Doesn’t work like this for me.
Downloads $ ls *.pkg
BusyCal Installer.pkg BusyContacts Installer.pkg
Downloads $ pkgutil –check-signature ~/Downloads/*.pkg
Package “BusyCal Installer.pkg”:
Status: signed by a certificate trusted by Mac OS X
Certificate Chain:
1. Developer ID Installer: BusyCal, LLC (N4RA379GBW)
SHA1 fingerprint: 28 B7 BE 6E 1A 2D 63 91 4C 38 28 8F FC AB 1F D2 03 B8 E6 CE
—————————————————————————–
2. Developer ID Certification Authority
SHA1 fingerprint: 3B 16 6C 3B 7D C4 B7 51 C9 FE 2A FA B9 13 56 41 E3 88 E1 86
—————————————————————————–
3. Apple Root CA
SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60