macOS certificate revocation gaps in command-line tools

On 19 October 2026, Apple automatically blocked twelve compromised certificates, followed by a thirteenth block of the emSign ECC Root CA - G3 on 23 October. While Safari and most native applications updated their trust settings immediately, command-line tools relying on static certificate stores remained vulnerable. This discrepancy created a split reality where the same machine could reject a certificate in a browser while accepting it in a terminal session.

What happened

The core issue stems from how different software components on macOS verify digital certificates. Apple’s security frameworks, which power Safari, Mail, and many other apps, use a dynamic system that checks against Apple’s block list and performs online revocation checks. However, certain tools shipped with macOS and the Xcode Command Line Tools do not use this dynamic system. Instead, they read a static flat file located at /etc/ssl/cert.pem. As of the week Apple published its advisory, this file had not been refreshed to reflect the new blocks. Apple confirmed in support article 149555 that these tools do not check the block list or verify whether a certificate has been revoked.

This fragmentation led to conflicting reports from operators and developers. Some noted that their built-in curl and git commands continued to connect to servers using the blocked certificates, while others claimed these tools respected the system trust settings. The confusion likely arises from differences in macOS versions, the use of Homebrew-installed tools versus system binaries, or misunderstandings about which certificate store a specific binary references. For instance, Homebrew maintains its own certificate bundle at /opt/homebrew/opt/ca-certificates, which updates independently of Apple’s OS updates. Similarly, language runtimes like Python often bundle their own certificate authorities via packages such as certifi, creating yet another isolated trust surface.

Key details

• Apple blocked twelve certificates on 19 October 2026 and the emSign ECC Root CA - G3 on 23 October 2026.
• Tools reading /etc/ssl/cert.pem do not check Apple’s block list or perform revocation checks.
• Manual remediation involves removing root certificates from the flat file, but macOS software updates can overwrite this file.
• At least four distinct verifiers exist on a single Mac: Apple frameworks, system LibreSSL, Homebrew bundles, and language runtime bundles.
• Apple advises administrators to re-check the certificate file after every OS update, as patches may revert manual changes.
• Conflicting reports about curl behavior suggest variations in tool sources or macOS versions among users.

Background

Certificate revocation is not an inherent property of the certificate itself but a decision made by the verifier checking it. When a certificate authority compromises keys or issues certificates incorrectly, they revoke them. However, for a client to respect this revocation, it must consult a current list of revoked certificates or check online in real time. In the macOS ecosystem, this process is fragmented. Apple’s keychain system is designed to be current and automatic, but legacy tools and third-party package managers often rely on static snapshots of trusted roots. These snapshots become stale until explicitly updated, creating windows of vulnerability where revoked certificates are still accepted as valid.

Why it matters

For teams managing self-hosted infrastructure or developing software on macOS, this fragmentation poses a significant security risk. If your deployment scripts, CI/CD pipelines, or monitoring tools rely on command-line utilities like curl or git, they may continue to trust compromised certificates even after Apple has blocked them. This means your automated systems could be communicating with malicious actors or insecure endpoints without raising any alarms. The silence of these tools is dangerous because they report successful connections, masking the underlying trust failure.

Furthermore, the recommended fix—manually editing the certificate file—is fragile. Since macOS updates can restore the original, unpatched version of /etc/ssl/cert.pem, a machine that was secured yesterday might be vulnerable again today after a routine system update. Without continuous verification, administrators cannot be sure which trust state their machines are in. This uncertainty complicates incident response and compliance auditing, as two identical-looking machines may have completely different security postures regarding certificate validation.

What you can do

• Identify which certificate store your critical tools are using by running verbose connection tests and checking for CAfile or CApath outputs.
• Compare the results of security verify-cert against your command-line tools to detect discrepancies in trust decisions.
• If you manually patch /etc/ssl/cert.pem, record the file hash and date, and re-verify it after every macOS software update.
• Consider pointing tools to a single, controlled certificate bundle using environment variables like CURL_CA_BUNDLE or SSL_CERT_FILE.
• Monitor your external-facing services for certificate validity and expiry to ensure your own infrastructure remains secure.
• Audit language-specific certificate bundles, such as Python’s certifi, and update them independently of the operating system.