Security certificates issued by Apple to developers can always be revoked. As we’ve seen in recent months, Apple isn’t above making mistakes, as it admitted it had when it revoked those of Charlie Monroe. When this happens, every Mac connected to the Internet becomes unable to run software signed by the revoked certificate: a rapid and severe consequence for both the developer and everyone who uses their software. How does that work, exactly?

Until a couple of years ago, it appeared that certificate revocations were stored in the Gatekeeper database at /private/var/db/gkopaque.bundle, and periodically refreshed in updates pushed by Apple. The last such update was released by Apple on 26 August 2019, version 181. On my iMac Pro, the database within that bundle hasn’t been updated or opened since 24 September 2019. In Sierra and later, there’s additional data stored in what we’ve known as the Gatekeeper ‘disk’, or GKE, at /private/var/db/gke.bundle, but that too hasn’t been updated or opened over that period.

Just to confound, there are also (at least)* two different types of code certificate checks, full and routine. Full checks occur when Gatekeeper looks at code with the quarantine flag set, but routine certificate checks are comonplace whenever code is loaded and run. The former normally requires the certificate (and any notarization) to be checked with Apple’s servers, but the latter doesn’t. For code with a revoked certificate to be rejected by a routine certificate check requires details of all revoked certificates to be held locally; but not apparently in either of the ‘Gatekeeper databases’, which now appear to be disused.

Then by accident, when looking at all the activities currently managed by Centralized Task Scheduling, I noticed one with the name com.apple.security.syspolicy.check.revocation, which is initially set to run every three days. It’s one of about ten different activities which CTS manages for macOS security system policy, and is loaded in the system LaunchDaemon property list com.apple.security.syspolicy.plist. Thus it appears that Macs now obtain their local list of revoked certificates through a daemon managed by CTS, rather than in one of the more traditional security databases, which in this case appear to be defunct.

This begs questions about how El Capitan, for example, might obtain details of the latest revocations, as it also hasn’t received any pushed updates over the last couple of years. But it does explain why Big Sur betas don’t seem to care whether they’re using gkopaque and gke bundles from a few years ago: as with Catalina, macOS 11.0 doesn’t use those old databases, instead updating the list of revoked certificates using com.apple.security.syspolicy.check.revocation. And I’m sure that a security researcher is just about to discover where macOS now stores its list of revoked certificates.

For the time being, SilentKnight and LockRattler will continue to report the installed version number of the gkopaque and gke bundles. You never know, Apple might start to use them again.

* There are several different processes which call for certificate checks, including AMFI (Apple Mobile File Integrity), which is a stickler, and TCC (the Privacy system), which seems generally more tolerant. Some require each certificate to be checked with Apple, which normally only occurs when the quarantine flag is set, but most don’t. However, if a certificate has been revoked by Apple, most if not all of those checks should fail, according to the ‘designated requirement’.