A revoked certificate is only revoked in the store that checks it

Guard — Thu, 29 Oct 2026 00:07:09 +0000

On 19 October 2026 Apple blocked twelve certificates. On 23 October it blocked one more: the emSign ECC Root CA - G3. Both actions were automatic for anything using Apple's security frameworks. Safari, Mail, and most apps: done, no action required.

Terminal is a different story. Some tools that ship with macOS and the Xcode Command Line Tools do not read Apple's trust settings. They read a flat file, /etc/ssl/cert.pem, and as of the week Apple published its advisory, that file had not been refreshed. Apple says so itself in support article 149555, and it says something worse in the same paragraph: those tools "don't check its block or whether the certificate was revoked."

So the same laptop can show you two different answers about the same certificate, and both of them are correct answers to different questions.

The part worth paying attention to

While reading around this, I found two write-ups that contradict each other on a basic fact.

One script author states that "macOS's built-in curl does not use the system trust store. It reads a flat file, /etc/ssl/cert.pem, and does not check revocation."

Another operator's notes on the same incident say: "On our Macs, /usr/bin/curl and /usr/bin/git still connected after this step, because they use Apple's trust settings."

Both are describing /usr/bin/curl on macOS in October 2026. One of them is wrong about the mechanism, or the mechanism differs by macOS version, or one of them is quietly running a Homebrew curl and reporting on the system one.

This is not trivia. Everything downstream depends on it: whether removing the roots from the file actually protects you, whether a patched machine is patched, whether the update reverted your patch, and whether you can write "fixed" in your incident log.

A revocation is not a property of a certificate

It is a property of a verifier. "Revoked" has no meaning until you name who is checking, against which store, with which rules, and how stale that store is.

For this incident, at least four verifiers are in play on one Mac:

Apple's frameworks, using the keychain plus Apple's block list and online revocation. Fast, automatic, current.
Tools compiled against the system LibreSSL that read /etc/ssl/cert.pem. Flat file, no revocation checking. Staleness is whatever the last OS update left there.
Homebrew's bundle at /opt/homebrew/opt/ca-certificates. Updated by brew, not by Apple.
Whatever a particular language runtime bundles. Python's certifi was affected here too and needed its own upgrade.

Four surfaces, four update paths, no shared clock. Apple's own remediation advice accounts for this. It tells administrators to remove the roots from /etc/ssl/cert.pem manually, and then warns them that "a macOS software update can replace /etc/ssl/cert.pem with Apple's version" and that they should re-run the check after every update.

Read that again. The recommended workaround can be silently undone by an unrelated OS update, and the only notice you get is a file that quietly went back to its old contents.

What a hand-patch does to your evidence

When you edit that file by hand, you create a fork. Your machine's trust is now neither Apple's nor the default: it is an artifact of a specific edit, made on a specific day, by a specific person, and it will diverge again at the next update with no record of which state you are actually in.

From the outside, two machines look identical. Both boot, both connect, both report a clean TLS handshake. One of them has Apple's fix, one has your patch, and one has your patch that an update already overwrote. The only way to tell them apart is to go look, on that machine, at that moment.

So measure it instead of assuming it:

# 1. Which store is this curl actually using?
/usr/bin/curl -v https://example.invalid 2>&1 | grep -i "CAfile\|CApath"

# 2. Does the Apple frameworks path agree?
security verify-cert -c test.pem

Then check the file itself, and check whether it still matches what you think you installed. A hash plus a date is enough. If you roll this out through MDM, log the hash you pushed and re-check it after every OS update, because the update is the event that matters, not the patch.

If instead you want one trust store whose update path you control, point the tools at Homebrew's bundle or a Mozilla bundle and set it once: CURL_CA_BUNDLE, GIT_SSL_CAINFO, SSL_CERT_FILE. That trades Apple's latency for your own discipline, which is a real trade and not obviously the better one.

The rule I keep

A warning has to name the verifier it speaks for, and its limits. "The certificate is revoked" is not a warning. It is a sentence with a subject missing.

The sentence that survives contact with a real machine looks like: Apple's frameworks rejected this chain on 19 October, your curl still accepts it because it reads a 128-entry file last written by the OS build you installed in June, and the fix you applied by hand will be overwritten by the next update.

Three clauses, all measurable, no assumptions about which store someone else's binary uses.

The compromise was real. Eight intermediate CAs, six of them TLS, keys in the wind. But the incident is not over when the vendor blocks it. It is over when you can say which of your verifiers knows that.

DEV Community: Guard

A revoked certificate is only revoked in the store that checks it

The part worth paying attention to

A revocation is not a property of a certificate

What a hand-patch does to your evidence

The rule I keep