About the compromised eMudhra intermediate CAs

An intermediate Certification Authority is a certificate-issuing authority beneath a root CA in the trust chain. It signs or issues certificates for websites, while the root CA provides the higher-level trust that browsers and tools recognize. This structure lets certificates be traced back to a trusted root.

For example, each of the six affected eMudhra TLS intermediate CAs had a certificate issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3. The same intermediate CA also had a cross-signed certificate chaining to Sectigo’s AAA Certificate Services.

The compromise mattered because private keys for intermediate CAs can authorize certificates for websites. Apple blocked the affected certificates automatically in its frameworks. Some command-line tools still rely on /etc/ssl/cert.pem, so they may continue trusting a chain until Apple updates that file.

The incident involved eight compromised intermediate CAs operated by eMudhra. Their private keys were exposed, creating a trust problem for certificates issued through those authorities. The number of affected authorities is larger than the number directly relevant to ordinary website connections.

Six of the eight intermediate CAs issued TLS certificates. The other two issued code-signing certificates, which Apple’s frameworks do not trust. Each of the six TLS intermediates had two certificates: one chaining through emSign Root TLS CA - G3 and another cross-signed by Sectigo, chaining to AAA Certificate Services.

That produces 12 affected TLS certificates in total. Apple began blocking those 12 certificates on 19 October 2026 and later began blocking emSign ECC Root CA - G3 on 23 October. eMudhra and Sectigo revoked the affected certificates.

The compromised private keys could let someone create TLS certificates claiming to represent any website. That is dangerous because a certificate is meant to connect a website’s identity with encrypted communication. A fraudulent certificate could therefore make an impostor site appear to have legitimate credentials.

The appearance of validity came from the certificate chain. The six affected eMudhra intermediates were recognized beneath trusted paths: one path used emSign Root TLS CA - G3 and emSign ECC Root CA - G3, while the other was cross-signed by Sectigo and chained to AAA Certificate Services. A tool following either trusted path could accept the resulting certificate.

This is why eMudhra and Sectigo revoked the affected certificates and Apple blocked them. However, the article notes that some command-line tools using /etc/ssl/cert.pem did not yet check Apple’s block or certificate revocation.

Apple devices automatically block the compromised certificates in Safari, Mail, and apps that use Apple’s networking and security frameworks. The block is delivered through certificate configuration data, so users do not need to install a software update for that protection. Most users therefore need to do nothing.

Some Mac command-line tools follow a different trust process. Tools included with macOS or the Xcode Command Line Tools, including curl, git, python3, ruby, perl, and openssl, can check certificates against /etc/ssl/cert.pem. When a certificate chains to a root listed there, these tools do not check Apple’s block or whether the certificate was revoked.

Apple plans to include the changes in a future software update. Until then, administrators who use these tools can remove the relevant root certificates from the file, although that may affect verification for some legitimate websites.

Each of the six affected TLS intermediate CAs had two certificates. One was issued by emSign Root TLS CA - G3 and chained to emSign ECC Root CA - G3. The other was cross-signed by Sectigo and chained to AAA Certificate Services. Thus, the article identifies two distinct certificate paths for each intermediate.

A tool checking a certificate can build a chain through either path if the relevant root is trusted. Removing emSign ECC Root CA - G3 removes the emSign-based path from /etc/ssl/cert.pem, but it does not remove AAA Certificate Services. The separate Sectigo chain can therefore remain trusted by tools using that file.

To block both paths in those tools, administrators would need to remove the relevant root certificates from the file, subject to the article’s warning about legitimate websites. Apple’s automatic frameworks-based block handles the affected certificates without this manual file editing.

Removing affected root CA certificates from /etc/ssl/cert.pem can prevent command-line tools that rely only on that file from accepting the compromised certificate chains. This gives administrators an earlier mitigation instead of waiting for Apple’s future macOS update. The change is local to tools that use that trust file.

There is a trade-off. After removal, those tools might not verify some legitimate websites whose certificates chain to the removed roots through intermediate CAs that were not affected. The article also warns that a macOS software update can replace the file with Apple’s version, restoring certificates that an administrator removed.

Administrators must repeat the removal after such updates until the software update containing Apple’s changes is installed. Apps and tools with their own root-certificate lists are different; they may ignore both Apple’s block and /etc/ssl/cert.pem, requiring guidance from their developers.

In the public-key infrastructure trust model, a browser or tool evaluates a website certificate through a chain of signed certificates. The website certificate is linked to an intermediate CA, and that intermediate links to a root CA already trusted by the device or tool. Valid signatures and matching chain relationships support the trust decision.

For this incident, the affected TLS intermediates had paths to emSign ECC Root CA - G3 or Sectigo’s AAA Certificate Services. A tool with the relevant root in its trust store could treat a certificate issued through that chain as valid. The compromised private keys undermined that assumption because they could produce certificates for any website.

Certificate revocation and explicit blocking can override ordinary chain trust. eMudhra and Sectigo revoked affected certificates, while Apple blocked the 12 certificates and emSign ECC Root CA - G3. Some tools using /etc/ssl/cert.pem did not yet apply those checks.