ItInsightsWorld Security Playbook: Closing the /etc/ssl/cert.pem Gap After the eMudhra TLS CA Compromise
Revocation on macOS is not a single switch — it is a stack of independent trust paths, and the eMudhra incident shows how far those paths can drift apart. On 19 October 2026 Apple began forcing distrust of certificates chaining to compromised eMudhra intermediate Certification Authorities (CAs) used for TLS, and further refinements to that block are already being delivered. System clients are covered: Safari, Mail and any application built on Apple networking and security frameworks reject the affected chains automatically. Automation is a different story, because curl, git, python3, ruby, perl and openssl validate against /etc/ssl/cert.pem instead of Apple's enforcement data. This Security briefing from ItInsightsWorld maps the split, gives managed Mac estates a scoping checklist, corrects the assumptions teams most often get wrong, and reproduces the optional Terminal procedure that closes the seam ahead of the vendor update.
Exposure snapshot at a glance
- Trigger: the private keys of eight intermediate CAs operated by eMudhra were compromised.
- Blast radius: Two of those intermediates issue code signing certificates, while six issue TLS certificates.
- Blocked objects: 12 certificates in total, two per TLS intermediate.
- Block start: 19 October 2026 on Apple devices, pushed as certificate configuration data rather than as a full OS install.
- Root-level extension: on 23 October 2026 Apple also began blocking emSign ECC Root CA - G3.
- Remaining seam: command-line tools from macOS and the Xcode Command Line Tools that read /etc/ssl/cert.pem; a future software update will cover them.
- Issuer response: eMudhra and Sectigo have revoked the affected certificates.
Incident anatomy: eight intermediates and one key-theft problem
The failure here is not a mis-issuance caught in a review log; it is lost key material. Someone holding the keys of any of the six TLS intermediates can construct certificates that appear valid for any website, so name, chain and signature all pass ordinary verification. Two of the compromised intermediates issue code signing certificates, and Apple's frameworks do not trust those.
Each of the 6 TLS intermediate CAs has two certificates, for 12 in total:
- One issued by emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3.
- One cross-signed by Sectigo, which chains to AAA Certificate Services.
The cross-signature is the detail that matters operationally: cutting one chain does not automatically cut the other, which is why the optional procedure below separates a primary root removal from an additional one.
Trust path matrix: which enforcement point covers what
| Consumption path | Typical examples | Honors Apple's block | Revocation consulted | State in this incident |
|---|---|---|---|---|
| Apple networking and security frameworks | Safari, Mail, framework-based apps on Mac | Yes | Framework validation | Blocked automatically; no user action required |
| Utilities that read /etc/ssl/cert.pem | curl, git, python3, ruby, perl, openssl from macOS or the Xcode Command Line Tools | No | No, when the chain terminates at a root inside that file | May still accept; corrected by a future software update |
| Applications shipping their own root list | Bundled runtimes and stand-alone tools | No | Determined by the app | Neither Apple's block nor /etc/ssl/cert.pem applies; contact the developer |
How Apple is delivering the block
Two delivery mechanics should be separated when you plan the change window. Device-side enforcement went live on 19 October 2026 and travels in certificate configuration data, sent automatically and as needed, so installing a software update is not required for that part; the further updates to the block follow the same automatic route, and emSign ECC Root CA - G3 was added to the deny list on 23 October 2026. The file-side work is slower: Apple is still preparing changes for other Mac locations where software checks certificates, including the command-line tools supplied with macOS or the Xcode Command Line Tools that use /etc/ssl/cert.pem. Those land in a future software update, and users will not need to edit files to receive them.
Scoping checklist before you touch /etc/ssl/cert.pem
- Confirm the inventory actually contains Mac endpoints driven from Terminal; users who do not use Terminal in their workflow have no action to take.
- List the automation that shells out to curl, git, python3, ruby, perl or openssl — build agents, CI runners, deployment scripts, security tooling and analyst laptops.
- For each tool, determine whether trust resolves through /etc/ssl/cert.pem or through a bundled root list; only the first group is addressed by the procedure below.
- Verify privileges: an administrator account is needed, or the commands must be deployable through your device management solution.
- Accept the blast radius: these steps affect every tool that uses /etc/ssl/cert.pem, and afterwards tools relying only on this file may not verify some websites whose certificates chain to these root CA certificates through unaffected intermediate CAs.
- Register a control point: a macOS software update can replace /etc/ssl/cert.pem with Apple's version, so re-verification after each update is mandatory until the patched release arrives.
- Record the risk decision: waiting for the scheduled update is a legitimate option; manual removal only shortens exposure.
Common misconceptions
- "The certificates were revoked, so every client is protected." Apple's block plus the revocation by eMudhra and Sectigo cover framework-based validation. For certificates that chain to a root CA certificate inside /etc/ssl/cert.pem, the command-line tools do not consult Apple's block or whether the certificate has been revoked.
- "Anyone with a Mac must act." Most users do not need to edit /etc/ssl/cert.pem. Safari, Mail and apps that use Apple's networking and security frameworks do not read that file, and they block these certificates automatically.
- "Deleting emSign ECC Root CA - G3 removes all 12 certificates." It does not block the six certificates that Sectigo cross-signed, because those tools can still verify them through AAA Certificate Services.
- "The file edit is permanent." A macOS software update can replace /etc/ssl/cert.pem with Apple's version, so the removed root can silently come back.
- "We have to do this manually." No. The vendor fix is coming in a future software update and users will not need to edit files to receive it; the manual route is optional.
- "Bundled runtimes inherit the same protection." Some applications and tools carry their own list of root CA certificates and use neither Apple's block nor /etc/ssl/cert.pem, so their behaviour is outside both enforcement points.
Optional Terminal procedure: trimming the roots from /etc/ssl/cert.pem
Rather than waiting for the upcoming software update, administrators can remove the root CA certificates to which the blocked certificates chain. Copy each command exactly as written, and check what to do if you get an alert about possible malware when pasting the command into Terminal.
Step 1: keep a backup of the file
If a backup already exists, this command keeps it:
[ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.origStep 2: remove emSign ECC Root CA - G3
The command builds a copy of the file without emSign ECC Root CA - G3, confirms the copy is not empty and then replaces the original. Success produces no output:
t=$(mktemp) && awk -v s='=== /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"Step 3 (optional): remove AAA Certificate Services
Because step 2 leaves the Sectigo cross-signed chain usable, stop these tools from accepting those six certificates through the file until Apple's software update is installed by also removing AAA Certificate Services. The command works the same way as the one in step 2:
t=$(mktemp) && awk -v s='=== /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services' '/^(===|###) /{skip=0} $0==s{skip=1} !skip' /etc/ssl/cert.pem > "$t" && [ -s "$t" ] && sudo install -m 0644 -o root -g wheel "$t" /etc/ssl/cert.pem; rm -f "$t"Step 4: confirm the result
This command lists either root CA certificate if it is still present. If you removed both, it shows nothing; if it errors, restore the backup taken in step 1:
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' .Post-change control loop
- Run the step 4 command after every software update while you are still waiting for Apple's changes; if it lists a root CA certificate you removed, the update replaced the file.
- In that case delete the old backup using sudo rm /etc/ssl/cert.pem.orig, then repeat the steps.
- After installing the update that contains Apple's changes, these steps are not needed for command-line tools included with macOS or the Xcode Command Line Tools.
Reference: the 12 blocked certificates
Both columns of issuer and anchor are kept explicit below, because each entry must be traced to the root removal that suppresses it.
| Certificate | Issued by | Root removed by the optional procedure | SHA-256 fingerprint |
|---|---|---|---|
| EM EV TLS CA - G3B | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838 |
| EM EV TLS CA - G3B | AAA Certificate Services | AAA Certificate Services (step 3, optional) | 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512 |
| EM OV TLS CA - G3B | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B |
| EM OV TLS CA - G3B | AAA Certificate Services | AAA Certificate Services (step 3, optional) | 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699 |
| EM DV TLS CA - G3B | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493 |
| EM DV TLS CA - G3B | AAA Certificate Services | AAA Certificate Services (step 3, optional) | 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE |
| EM EV TLS CA - G3C | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3 |
| EM EV TLS CA - G3C | AAA Certificate Services | AAA Certificate Services (step 3, optional) | FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F |
| EM OV TLS CA - G3C | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F |
| EM OV TLS CA - G3C | AAA Certificate Services | AAA Certificate Services (step 3, optional) | 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489 |
| EM DV TLS CA - G3C | emSign Root TLS CA - G3 | emSign ECC Root CA - G3 (step 2) | 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19 |
| EM DV TLS CA - G3C | AAA Certificate Services | AAA Certificate Services (step 3, optional) | 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72 |
FAQ
Does Safari need any protection against these certificates?
No. Safari, Mail and apps that use Apple's networking and security frameworks do not read /etc/ssl/cert.pem, and Apple devices already block these certificates inside them.
Which Mac tooling is still exposed?
Command-line tools included with macOS or the Xcode Command Line Tools that check certificates against /etc/ssl/cert.pem — including curl, git, python3, ruby, perl and openssl — can keep accepting them until a future software update.
Do administrators have to edit the file?
Not necessarily. Apple says the file will be updated in a future macOS update, and users will not need to edit files to receive it. Removing root CA certificates from the file is only a way to stop the tools sooner.
Why are there 12 certificates if only six TLS intermediates are involved?
Each of the 6 TLS intermediate CAs has two certificates: one issued by emSign Root TLS CA - G3 and one cross-signed by Sectigo, so the same authority can be reached through two different trust anchors.
Could the manual removal break legitimate sites?
Yes. After the change, tools that use only this file may not verify some websites whose certificates chain to these root CA certificates through unaffected intermediate CAs.
We ship an application with its own CA bundle — is it covered?
No enforcement point described here applies automatically. Some applications and tools carry their own list of root CA certificates and do not use Apple's block or /etc/ssl/cert.pem; for those apps or tools, contact the developer.
Action recommendations
- Confirm automatic protection first: verify that user-facing Mac workloads run through Safari, Mail or Apple framework-based apps, where the block already applies.
- Build the exposure register for Terminal-driven tooling, naming every host or pipeline that uses curl, git, python3, ruby, perl or openssl against /etc/ssl/cert.pem.
- Choose an enforcement route explicitly — wait for the future macOS update, or deploy the optional removal now with an administrator account or your device management solution.
- If you deploy, take the backup in step 1, remove emSign ECC Root CA - G3 in step 2, and evaluate step 3 only where the Sectigo cross-signed chain must also stop validating through the file.
- Gate every remediation with the verification command in step 4, and treat an error in that output as a trigger to restore the step 1 backup.
- Insert the step 4 check into your patch workflow: rerun it after each software update, delete the stale /etc/ssl/cert.pem.orig backup and repeat the steps if Apple's version of the file returns.
- Track third-party tools with bundled trust stores as a separate item and raise them with the respective developers.
- Retire the workaround once the update containing Apple's changes is installed, since the steps are then not needed for the command-line tools included with macOS or the Xcode Command Line Tools.
For the majority of Mac users this incident stays invisible, handled by automatic enforcement. For platform and security teams the lesson is structural: trust validation on macOS is layered, and any automation terminating at /etc/ssl/cert.pem belongs in the same tracking queue as the endpoints already covered by Apple's block. Source note: this briefing reflects advisory information published on October 23, 2026, brought to you by the ItInsightsWorld Security desk.