Apple's bundled macOS git still trusts compromised eMudhra certificates in the keychain

Apple's git reads trust from the keychain

macOS ships its own copy of git at /usr/bin/git, and unlike a typical OpenSSL-based build it does not fall back on OpenSSL's default trust store. According to a write-up published on dev.to, Apple's git validates TLS certificates against the macOS keychains instead. That detail is the root of the problem: a certificate that has been revoked elsewhere can still validate on a Mac as long as a copy of it remains in the system or login keychain. The certificates in question are compromised ones tied to eMudhra, and the author warns that automated builds may be silently accepting revoked identities as a result.

Finding the certificates

The detection approach in the post is a short pipeline: dump every certificate from the system keychain with security find-certificate, pass the output through openssl x509 to print each entry's subject and issuer, and grep the result for "emudhra". Aimed at /Library/Keychains/System.keychain, an empty result means the store is clean; any lines of output mean a compromised certificate that git will still trust is sitting on the machine.

Deleting them

Removal follows the same pattern. The post's script collects SHA-256 fingerprints from the system keychain, filters for eMudhra entries, strips the colon formatting, and calls security delete-certificate -Z with each fingerprint, running under sudo when permissions require it. To verify the cleanup worked, re-run the detection scan and confirm it returns nothing. The author also suggests exercising git directly, running a command such as git ls-remote against a remote like github.com and confirming that no certificate errors appear.

Where the cleanup falls short

The post lists three failure modes that a system-keychain-only fix misses. First, the removal script never touches the login keychain, so the same certificate imported into ~/Library/Keychains/login.keychain-db survives; the check has to be repeated there. Second, git installed through Homebrew may bring its own OpenSSL configuration and ignore the system keychain entirely, and git config --get http.sslBackend will reveal which backend is actually in use. Third, some tools cache TLS sessions, so stale connections can persist until the terminal is restarted or the machine is rebooted.

Keeping CI runners honest

Prebuilt macOS images used by CI runners may still contain the old certificates, which means a machine cleaned today can be re-provisioned tomorrow with the bad trust restored. The post's answer is a pipeline guard: a verification step, demonstrated as a GitHub Actions job on macos-latest, that counts eMudhra matches in the system keychain and exits with a non-zero status if the count is greater than zero. The build fails loudly rather than letting the certificates slip back in unnoticed.

Why it matters

Revocation is only meaningful if clients actually stop trusting the revoked thing. Here the trust decision lives in a per-machine store that Apple's git consults directly, so nothing short of deleting the certificate fixes a given Mac, and ephemeral CI images can quietly reintroduce the problem after every cleanup. The blast radius is build infrastructure: if a revoked identity still validates, the TLS check git relies on to confirm that a remote is genuine stops doing its job, and builds can fetch code and dependencies from a host they should have rejected. The post's checklist, scanning both keychains, knowing which TLS backend your git uses, and gating CI on a clean trust store, converts a silent security failure into a visible one.