# macOS 27.2.1 stops curl trusting eMudhra. Here is what I would check in my Mac app

> On November 9, 2026, Apple shipped macOS 27.2.1, with 26.7.3 and 15.8.3 for older Macs. Besides eight security fixes, they close a gap left by the eMudhra certificate compromise: since October 19, Safari, Mail and apps using Apple's networking and security frameworks already refused 12 bad certificates, but command-line tools like curl, git, python3 and openssl read /etc/ssl/cert.pem and kept accepting them. The updates remove five root certificates from that file, including AAA Certificate Services. If your app, installer or update script uses those tools, or ships its own list of trusted roots, test your downloads and your own servers on the new versions.

By Justinas Rolando, maker of MacPip. Published November 11, 2026. Page: https://macpip.com/blog/macos-27-2-1-emudhra-certificates-mac-apps

Most Mac updates I install and forget. macOS 27.2.1, out on November 9, is one I'd read the small print of if I made a Mac app, because it changes which certificates some of the tools on every Mac trust. Apple shipped it with [macOS Tahoe 26.7.3 and Sequoia 15.8.3](https://support.apple.com/en-us/100100) for older Macs, and all three carry the same change.

Here's what happened, who it reaches, and what I'd test.

## What happened

- **Eight intermediate certificate authorities were compromised.** Apple's [support page on eMudhra](https://support.apple.com/en-us/149555) says the private keys of eight eMudhra intermediate CAs were compromised. Six of them issue the certificates websites use for https. With those keys, someone could make a certificate that looks valid for any site. eMudhra and Sectigo revoked the affected certificates.
- **The keys were tiny.** [MacRumors](https://www.macrumors.com/2026/11/09/macos-27-2-1-emudhra-fix/) reports that a Mozilla investigation found key values so small they were trivial to recover. MacRumors also [said in October](https://www.macrumors.com/2026/10/25/apple-blocks-compromised-emudhra-certificates/) that there was no evidence the keys had been used.
- **Apple blocked them in October, but not everywhere.** Starting October 19, Apple blocked 12 of these certificates in Safari, Mail and apps that use Apple's networking and security frameworks, with no update needed.
- **Command-line tools were the gap.** Apple's page names curl, git, python3, ruby, perl and openssl. They check certificates against the file `/etc/ssl/cert.pem`, and for anything that chains to a root in that file, they skip Apple's block.
- **27.2.1 closes it.** The command-line tools stop accepting these certificates, and five roots are removed from `/etc/ssl/cert.pem`: emSign ECC Root CA - G3, AAA Certificate Services, emSign Root CA - G1, emSign Root CA - C1 and emSign ECC Root CA - C3. Apple's page says 26.7.3 and 15.8.3 include the same protection.

The same updates fix eight other security bugs, in Messages, AirPlay and Bluetooth, per [MacRumors](https://www.macrumors.com/2026/11/09/ios-27-2-1-security-fixes/). Apple didn't say any were used in attacks.

## Why a Mac app maker should care

If your app is a normal Swift app that talks to the internet with `URLSession`, it was most likely covered in October. Apple's page talks about apps that use its networking and security frameworks, and [Howard Oakley, quoted by Michael Tsai](https://mjtsai.com/blog/2026/10/29/emudhra-intermediate-ca-compromise/), says apps built on Apple's standard APIs use the macOS trust store.

The apps that weren't covered are the ones a lot of indie makers ship:

- **Apps that run curl, git or python3 under the hood.** Download helpers, install scripts, model downloaders for [local AI apps](/category/ai), developer tools that wrap git.
- **Apps with their own list of trusted roots.** Oakley names Chrome and other Chromium browsers, Mozilla and Microsoft products, and some Electron apps. He also says Python, Java and Go, and possibly Rust or Ruby, may be affected. Apple's page says tools with their own root list don't use its block or `/etc/ssl/cert.pem` at all.

So the October fix may not have reached your app, and the November fix may not either if it brings its own roots.

There's a second side. AAA Certificate Services is an old Sectigo root that has signed plenty of ordinary certificates. Apple's page warns that tools using only `/etc/ssl/cert.pem` may fail to verify some sites whose chains run through the removed roots. If your download server, update feed or license API happens to be one of them, curl on an updated Mac could start refusing it.

## What I'd check this week

These are my own steps, not Apple's.

1. **Update one Mac to 27.2.1 and test downloads from the command line.** Run your install script, your `brew install` if you have a cask, and `curl -I` against your download, appcast and license addresses. A refused certificate shows up as an error, not a slow page.
2. **Look at your own certificate chain.** Run `openssl s_client -connect yourapp.com:443 -showcerts` and read the issuer lines. If you see eMudhra, emSign or AAA Certificate Services, ask your host or certificate seller for a chain that ends at another root.
3. **Find the trust store your app really uses.** Electron, Go, Rust with bundled roots, Python with certifi and Java all bring their own. Update the runtime or the root package to a version that drops the bad certificates, and note it in your release notes.
4. **Have a support answer ready.** If someone on an older Mac can't install updates, Apple's page has steps to remove the roots by hand. I'd link to Apple's page rather than paste commands that use sudo into an email.
5. **Tell people to update.** If your app's users lean technical, a short note in your next release or newsletter costs nothing.
6. **Check the file on a test Mac.** Apple's page gives the command below, which prints nothing once the two key roots are gone.

```
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'
```

## What I wouldn't do

I wouldn't turn off certificate checks in a script to make an error go away. That's the one thing this whole change is protecting against. And I wouldn't tell users their Mac was hacked. There's no sign the keys were used, and most apps were protected in October.

## The MacPip angle

MacPip doesn't check which certificates an app trusts. Listings are [scanned automatically](/about) when they're submitted, and a blue tick only means a person tried the app on a date. If you make a [developer tool](/category/developer-tools) or a [security and privacy app](/category/security-privacy), you're the most likely to have a script or bundled runtime this touches, so it's worth an hour.

New today: the [privacy manifest checker](/tools/privacy-manifest-checker). Paste your `PrivacyInfo.xcprivacy` and it checks each data type, purpose and required reason code, such as `CA92.1`, against Apple's own lists. It also says what Apple asks for on the Mac and what it doesn't. It runs on the page and nothing is sent. The [Info.plist explainer](/tools/info-plist-explainer) and the [notarization explainer](/tools/notarization-explainer) are next door. And if your Mac app isn't on MacPip yet, [listing it is free](/submit).

## Sources
- [Apple Support: About the eMudhra certificate authority compromise (published November 9, 2026)](https://support.apple.com/en-us/149555)
- [Apple Support: Apple security releases](https://support.apple.com/en-us/100100)
- [MacRumors: macOS 27.2.1 Fixes eMudhra Certificate Flaw in Command-Line Tools](https://www.macrumors.com/2026/11/09/macos-27-2-1-emudhra-fix/)
- [MacRumors: Apple blocks compromised eMudhra certificates (October 25, 2026)](https://www.macrumors.com/2026/10/25/apple-blocks-compromised-emudhra-certificates/)
- [MacRumors: Here's What Apple Fixed in iOS 27.2.1 and macOS 27.2.1](https://www.macrumors.com/2026/11/09/ios-27-2-1-security-fixes/)
- [Michael Tsai: eMudhra Intermediate CA Compromise](https://mjtsai.com/blog/2026/10/29/emudhra-intermediate-ca-compromise/)