SponsorInloggenIndienen
Blog

macOS 27.2.1 laat curl eMudhra niet meer vertrouwen. Dit zou ik controleren in mijn Mac-app

Door Justinas Rolando, maker van MacPip

Kort antwoord

Op 9 november 2026 bracht Apple macOS 27.2.1 uit, met 26.7.3 en 15.8.3 voor oudere Macs. Naast acht beveiligingsfixes sluiten ze een gat dat de eMudhra-certificaatcompromittering achterliet: sinds 19 oktober weigerden Safari, Mail en apps die de netwerk- en beveiligingsframeworks van Apple gebruiken al 12 slechte certificaten, maar opdrachtregeltools als curl, git, python3 en openssl lazen /etc/ssl/cert.pem en bleven ze accepteren. De updates verwijderen vijf rootcertificaten uit dat bestand, waaronder AAA Certificate Services. Gebruikt je app, installer of updatescript die tools, of levert hij een eigen lijst van vertrouwde roots mee, test dan je downloads en je eigen servers op de nieuwe versies.

De meeste Mac-updates installeer ik en vergeet ik weer. macOS 27.2.1, uitgebracht op 9 november, is er een waarvan ik het kleine lettertje zou lezen als ik een Mac-app maakte, want het verandert welke certificaten sommige tools op elke Mac vertrouwen. Apple bracht het uit met macOS Tahoe 26.7.3 en Sequoia 15.8.3 voor oudere Macs, en alle drie hebben dezelfde wijziging.

Dit is wat er gebeurde, wie het raakt en wat ik zou testen.

Wat er gebeurde

Dezelfde updates verhelpen acht andere beveiligingsfouten, in Berichten, AirPlay en Bluetooth, volgens MacRumors. Apple zegt niet dat er een bij aanvallen is gebruikt.

Waarom een maker van Mac-apps hierom moet geven

Als je app een gewone Swift-app is die met URLSession met internet praat, was hij in oktober waarschijnlijk al gedekt. De pagina van Apple spreekt over apps die de netwerk- en beveiligingsframeworks van Apple gebruiken, en Howard Oakley, geciteerd door Michael Tsai, zegt dat apps die op de standaard-API's van Apple gebouwd zijn de trust store van macOS gebruiken.

De apps die niet gedekt waren, zijn die welke veel onafhankelijke makers uitbrengen:

Dus de oktoberfix heeft je app misschien niet bereikt, en de novemberfix mogelijk ook niet als hij eigen roots meebrengt.

Er is ook een andere kant. AAA Certificate Services is een oude Sectigo-root die veel gewone certificaten heeft ondertekend. Apple waarschuwt op de pagina dat tools die alleen /etc/ssl/cert.pem gebruiken sommige sites mogelijk niet kunnen verifiëren als hun keten via de verwijderde roots loopt. Is je downloadserver, updatefeed of licentie-API er zo een, dan kan curl op een geüpdatete Mac hem gaan weigeren.

Wat ik deze week zou checken

Dit zijn mijn eigen stappen, niet die van Apple.

  1. Update één Mac naar 27.2.1 en test downloads vanaf de opdrachtregel. Draai je installatiescript, je brew install als je een cask hebt, en curl -I op je download-, appcast- en licentieadressen. Een geweigerd certificaat verschijnt als fout, niet als trage pagina.
  2. Bekijk de certificaatketen van je eigen site. Voer openssl s_client -connect yourapp.com:443 -showcerts uit en lees de issuer-regels. Zie je eMudhra, emSign of AAA Certificate Services, vraag dan je host of certificaatverkoper om een keten die op een andere root eindigt.
  3. Zoek uit welke trust store je app echt gebruikt. Electron, Go, Rust met meegeleverde roots, Python met certifi en Java brengen allemaal hun eigen mee. Update de runtime of het rootpakket naar een versie die de slechte certificaten weglaat, en vermeld het in je releasenotities.
  4. Houd een supportantwoord klaar. Als iemand met een oudere Mac geen updates kan installeren, staan op de pagina van Apple de stappen om de roots met de hand te verwijderen. Ik zou naar de pagina van Apple linken in plaats van commando's met sudo in een e-mail te plakken.
  5. Vertel mensen dat ze moeten updaten. Als de gebruikers van je app technisch aangelegd zijn, kost een korte notitie in je volgende release of nieuwsbrief niets.
  6. Controleer het bestand op een test-Mac. De pagina van Apple geeft het commando hieronder, dat niets toont zodra de twee belangrijkste roots weg zijn.
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

Wat ik niet zou doen

Ik zou certificaatcontroles in een script niet uitzetten om een fout te laten verdwijnen. Dat is precies waartegen deze hele wijziging beschermt. En ik zou gebruikers niet vertellen dat hun Mac is gehackt. Er is geen teken dat de sleutels gebruikt zijn en de meeste apps waren in oktober al beschermd.

De MacPip-invalshoek

MacPip controleert niet welke certificaten een app vertrouwt. Vermeldingen worden automatisch gescand als ze worden ingestuurd, en een blauwe vink betekent alleen dat iemand de app op een bepaalde datum heeft uitgeprobeerd. Maak je een ontwikkeltool of een beveiligings- en privacy-app, dan heb je de meeste kans op een script of meegeleverde runtime waar dit aan raakt, dus het is een uurtje waard.

Nieuw vandaag: de privacymanifest-checker. Plak je PrivacyInfo.xcprivacy en hij controleert elk datatype, elk doel en elke verplichte redencode, zoals CA92.1, tegen de eigen lijsten van Apple. Hij zegt ook wat Apple op de Mac vraagt en wat niet. Hij draait op de pagina en er wordt niets verstuurd. De Info.plist-uitleg en de notarisatie-uitleg staan er direct naast. En staat je Mac-app nog niet op MacPip, dan is aanmelden gratis.

Bronnen

Lees verder

Dien je app inGratis tools voor makers