Apple blocks compromised eMudhra certificates and guides admins on CLI remediation

Apple has initiated a security response to block certificates issued by compromised eMudhra intermediate Certification Authorities. Starting 19 October 2026, the company began automatically blocking these credentials on its devices while providing specific manual remediation steps for system administrators who rely on command-line interfaces.

What happened

The security incident stems from the compromise of private keys belonging to eight intermediate Certificate Authorities operated by eMudhra. While two of these authorities issue code signing certificates that Apple frameworks do not trust, the other six issue Transport Layer Security (TLS) certificates. This distinction is critical because an attacker possessing these compromised keys could generate valid-looking TLS certificates for any website, potentially enabling man-in-the-middle attacks or impersonation of legitimate services.

In response, both eMudhra and Sectigo have revoked the affected certificates. The scope of the issue involves twelve specific certificates associated with the six TLS-issuing intermediate CAs. Each of these six authorities holds two certificates: one issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3, and another cross-signed by Sectigo, which chains to AAA Certificate Services. Apple has identified these twelve certificates as the primary vectors for potential abuse and has moved to neutralize them across its ecosystem.

Key details

• Apple began blocking the twelve compromised certificates on all Apple devices on 19 October 2026.
• The block applies automatically to Safari, Mail, and apps using Apple’s native networking and security frameworks.
• On 23 October 2026, Apple expanded the block to include the emSign ECC Root CA - G3 root certificate.
• Command-line tools such as curl, git, python3, ruby, perl, and openssl may still accept these certificates if they rely on the local /etc/ssl/cert.pem file.
• Apple will deliver a future software update to fix the command-line tool vulnerability, but no immediate OS update is required for general users.
• Administrators can manually remove the compromised root certificates from /etc/ssl/cert.pem to protect CLI workflows before the official patch arrives.

Background

To understand the impact, it helps to distinguish between how different applications verify identity on macOS. Most consumer-facing apps, including web browsers like Safari, use Apple’s centralized security frameworks. These frameworks receive updated blocklists over the air, allowing Apple to revoke trust in compromised certificates instantly without requiring a full operating system update. This mechanism protects the vast majority of users automatically.

However, many development and system administration tools operate differently. Utilities like curl and git often bypass Apple’s central trust store and instead check against a local file named /etc/ssl/cert.pem. This file contains a bundle of trusted root certificates stored directly on the disk. Because these tools do not query Apple’s live blocklist, they remain vulnerable to the compromised eMudhra certificates until the local file is either manually edited by an administrator or replaced by a future software update from Apple.

Why it matters

For teams that manage their own infrastructure or develop software on macOS, this gap in automatic protection presents a tangible risk. If your deployment scripts, CI/CD pipelines, or monitoring agents use command-line tools to connect to external services, they might inadvertently trust a malicious server presenting a forged certificate. This could lead to data exfiltration or the injection of malicious code during automated updates, as the tools would perceive the connection as secure.

Furthermore, the manual remediation process requires careful execution. Editing system-level certificate stores is a sensitive operation. Removing the wrong root certificate could break connectivity to legitimate services that happen to chain through the same roots. Administrators must balance the urgency of closing the security hole with the need to maintain operational stability. The fact that Apple plans to fix this in a future update means that any manual changes made now may need to be reverted or managed carefully to avoid conflicts when the official patch arrives.

What you can do

• Verify if your workflow uses Terminal-based tools like curl, git, or python3 that rely on /etc/ssl/cert.pem for certificate validation.
• Back up the current certificate file by running [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig in Terminal.
• Remove the emSign ECC Root CA - G3 certificate from the local trust store using the specific awk command provided by Apple to ensure the file remains valid.
• Optionally remove the AAA Certificate Services root if you need to block the Sectigo-cross-signed certificates immediately, understanding this may affect other services.
• Validate your changes by running the openssl verification command to confirm the compromised roots are no longer present in the file.
• Monitor for the upcoming macOS software update that will officially patch /etc/ssl/cert.pem, and restore the original backup if the update replaces your manual edits.