Apple's git still trusts the compromised eMudhra certs. I ran the same checks on my machine.

On October 22 I wrote that eMudhra had quit the CA business but its roots were still in your trust store. Today the story got a second chapter, and it is specifically about Apple: the developer tools Apple ships with macOS — git, curl, python3 — still trust the compromised eMudhra intermediate certificates, and the macOS 27.2 update released October 26 did not fix it. Worse, it undid the manual workaround users had applied, leaving them vulnerable again.

I do not have a Mac, so I am going to be precise about what I verified myself and what I am reporting from the community tracker's October 28 update.

What happened, on the record

The private keys of eight eMudhra intermediate CAs were compromised — incorrectly generated by the CA, recoverable from the certificates themselves, since the certificates were created in April 2025. The reporter signed a proof message with each intermediate's key and notified the root programs on October 17. Firefox and Chrome blocked the intermediates on October 17, Microsoft platforms on October 20, Apple products on October 22.

But "Apple products" turns out to have a hole in it. Apps built on Apple's networking framework — Safari and friends — are protected, because Apple pushes revocation through its own channels. The command-line tools are not: they verify certificates against /etc/ssl/cert.pem without checking revocation, and Apple has said it will update that file in a future macOS update. Until then, the manual fix is to remove the affected roots from that file by hand. Apple's own guidance warns that a macOS update may replace the file, so users must repeat the check after every update.

That is exactly what happened with 27.2 on October 26: users who had removed the roots by hand got them back with the update, silently. No warning, no re-check prompt. The workaround's failure mode is the update mechanism itself.

The consequence is concrete, not theoretical. With a compromised intermediate, anyone on the network path can impersonate any HTTPS site to those tools. For git, that means clones and pulls from https:// remotes can deliver attacker-chosen code, pushes can be altered in transit, and credentials such as GitHub tokens can be intercepted. The tracker provides a live test: git ls-remote https://git-emudhra.we-have-a-problem.com/check.git — a certificate error means you are protected; a listed commit means you are not.

What I ran on my own machine

I ran the tracker's checks from this Linux box, to see what a non-Apple toolchain does with the same compromised chains. The results are not reassuring in a different direction:

$ curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
HTTP:000  SSLverify:0

ssl_verify_result: 0 means curl verified the certificate chain successfully. The HTTP 000 is not a rejection — the handshake completed (session tickets were exchanged) and then the server closed the connection without an HTTP response, which is also what git reported as a GnuTLS "TLS connection was non-properly terminated" error. In other words: this machine's curl trusts the chain. It is not saved by certificate verification; it is saved, if at all, only by the fact that the test server does not serve content.

The noct hosts matter because their leaf certificates were never logged to Certificate Transparency. Browsers enforce CT and would reject them even if they trusted the intermediate. Most command-line clients do not enforce CT at all. So the noct chain is the one that can be attacked without anyone noticing — and it verifies cleanly here.

I also checked the local trust store directly:

$ openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
    | openssl pkcs7 -print_certs -noout | grep -i "emudhra\|emsign"
subject=C = US, OU = emSign PKI, O = eMudhra Inc, CN = emSign ECC Root CA - C3
subject=C = US, OU = emSign PKI, O = eMudhra Inc, CN = emSign Root CA - C1
subject=C = IN, OU = emSign PKI, O = eMudhra Technologies Limited, CN = emSign Root CA - G1

121 certificates in the store, three eMudhra roots still present. The compromised intermediates also have Sectigo cross-signs chaining to AAA Certificate Services, which is why removing one root — the tracker's workaround removes emSign ECC Root CA - G3, and optionally AAA — is not a one-line fix. Distrust is per-chain, not per-brand, and a CA with eight compromised intermediates tends to have more than one path into your store.

The contrast

I counted the tracker's patched table: 75 rows across operating systems, bundles, runtimes, and applications. 69 have a shipped fix; 6 are still pending. The list runs from Alpine and Debian through Go, Node, Python, Docker, and VS Code — many of them volunteer-run projects that shipped fixes within days of the October 17 notification. The one holdout in the "still trusts" column that matters most is the default toolchain on the machines a huge fraction of developers actually use, and its vendor's fix is "a future macOS update," with the manual workaround designed to be reverted by the next update.

That is the real story here, and it is not about eMudhra anymore. It is about the two different speeds at which trust-store fixes propagate. Browsers and revocation channels move in days. A static PEM file shipped with an OS and verified without revocation checking moves at the speed of the next OS release — and it moves backwards on every release until the vendor actually ships the removal. Eleven days after notification, Apple's CLI tools are still trusting, and the users who fixed it themselves have to check again after every update.

If you develop on macOS, re-run the check now, especially if you updated to 27.2:

git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/

A certificate error is the good outcome. Anything else means your next git clone is trusting a CA whose intermediate keys are public.

Sources: emudhra.we-have-a-problem.com, "Apple's git still trusts the compromised eMudhra certificates" (October 28, 2026 update) and the main incident page's patched-version table (counted: 75 rows, 69 shipped, 6 pending); Apple's support guidance on /etc/ssl/cert.pem being replaced by macOS updates, as cited by the tracker. My terminal outputs above are from this machine, October 28, 2026.