Lücken bei der Zertifikatswiderrufung in macOS-Befehlszeilentools

Am 19. Oktober 2026 hat Apple automatisch zwölf kompromittierte Zertifikate blockiert, gefolgt von einer dreizehnten Blockierung des emSign ECC Root CA - G3 am 23. Oktober. Während Safari und die meisten nativen Anwendungen ihre Vertrauenseinstellungen sofort aktualisierten, blieben Befehlszeilentools, die auf statischen Zertifikatsspeichern beruhen, verwundbar. Diese Diskrepanz führte zu einer gespaltenen Realität, in der derselbe Rechner ein Zertifikat im Browser ablehnen konnte, es jedoch in einer Terminal-Sitzung akzeptierte.

Was passiert ist

Das Kernproblem liegt darin, wie verschiedene Softwarekomponenten unter macOS digitale Zertifikate überprüfen. Apples Sicherheits-Frameworks, die Safari, Mail und viele andere Apps antreiben, nutzen ein dynamisches System, das gegen Apples Sperrliste prüft und Online-Widerrufsüberprüfungen durchführt. Bestimmte Tools, die mit macOS und den Xcode Command Line Tools geliefert werden, verwenden dieses dynamische System jedoch nicht. Stattdessen lesen sie eine statische Datei unter /etc/ssl/cert.pem. In der Woche, in der Apple seine Warnung veröffentlichte, war diese Datei nicht aktualisiert worden, um die neuen Sperren widerzuspiegeln. Apple bestätigte im Support-Artikel 149555, dass diese Tools weder die Sperrliste prüfen noch verifizieren, ob ein Zertifikat widerrufen wurde.

Diese Fragmentierung führte zu widersprüchlichen Berichten von Betreibern und Entwicklern. Einige stellten fest, dass ihre integrierten curl- und git-Befehle weiterhin Verbindungen zu Servern herstellten, die die blockierten Zertifikate verwendeten, während andere behaupteten, diese Tools würden die Systemeinstellungen für Vertrauen respektieren. Die Verwirrung entsteht wahrscheinlich durch Unterschiede in den macOS-Versionen, die Nutzung von Homebrew-installierten Tools im Vergleich zu System-Binärdateien oder Missverständnisse darüber, welchen Zertifikatsspeicher eine bestimmte Binärdatei referenziert. Beispielsweise pflegt Homebrew sein eigenes Zertifikatsbündel unter /opt/homebrew/opt/ca-certificates, das unabhängig von Apples OS-Updates aktualisiert wird. Ähnlich bündeln Sprachumgebungen wie Python oft ihre eigenen Zertifizierungsstellen über Pakete wie certifi, was eine weitere isolierte Vertrauensfläche schafft.

Wichtige Details

• Apple blockierte zwölf Zertifikate am 19. Oktober 2026 und das emSign ECC Root CA - G3 am 23. Oktober 2026.
• Tools, die /etc/ssl/cert.pem lesen, prüfen weder Apples Sperrliste noch führen sie Widerrufsüberprüfungen durch.
• Manuelle Abhilfe erfordert das Entfernen von Wurzelzertifikaten aus der statischen Datei, aber macOS-Softwareupdates können diese Datei überschreiben.
• Auf einem einzelnen Mac existieren mindestens vier unterschiedliche Verifizierer: Apple-Frameworks, systemseitiges LibreSSL, Homebrew-Bündel und Bündel von Sprachumgebungen.
• Apple rät Administratoren, die Zertifikatsdatei nach jedem OS-Update erneut zu prüfen, da Patches manuelle Änderungen rückgängig machen können.
• Widersprüchliche Berichte über das Verhalten von curl deuten auf Variationen bei den Tool-Quellen oder macOS-Versionen der Benutzer hin.

Hintergrund

Die Widerrufung eines Zertifikats ist keine inhärente Eigenschaft des Zertifikats selbst, sondern eine Entscheidung des Verifizierers, der es prüft. Wenn eine Zertifizierungsstelle Schlüssel kompromittiert oder Zertifikate fehlerhaft ausstellt, widerruft sie diese. Damit ein Client diesen Widerruf respektiert, muss er eine aktuelle Liste widerrufener Zertifikate konsultieren oder online in Echtzeit prüfen. Im macOS-Ökosystem ist dieser Prozess fragmentiert. Apples Keychain-System ist darauf ausgelegt, aktuell und automatisch zu sein, aber Legacy-Tools und Paketmanager von Drittanbietern verlassen sich oft auf statische Momentaufnahmen vertrauenswürdiger Wurzelzertifikate. Diese Momentaufnahmen veralten, bis sie explizit aktualisiert werden, wodurch Zeitfenster der Verwundbarkeit entstehen, in denen widerrufene Zertifikate weiterhin als gültig akzeptiert werden.

Warum das wichtig ist

Für Teams, die selbst gehostete Infrastruktur verwalten oder Software unter macOS entwickeln, stellt diese Fragmentierung ein erhebliches Sicherheitsrisiko dar. Wenn Ihre Deployment-Skripte, CI/CD-Pipelines oder Monitoring-Tools auf Befehlszeilen-Dienstprogramme wie curl oder git angewiesen sind, könnten sie kompromittierten Zertifikaten weiterhin vertrauen, selbst nachdem Apple sie blockiert hat. Das bedeutet, dass Ihre automatisierten Systeme mit böswilligen Akteuren oder unsicheren Endpunkten kommunizieren könnten, ohne Alarm zu schlagen. Die Stille dieser Tools ist gefährlich, weil sie erfolgreiche Verbindungen melden und damit das zugrunde liegende Vertrauensversagen verschleiern.

Darüber hinaus ist die empfohlene Lösung – die manuelle Bearbeitung der Zertifikatsdatei – fragil. Da macOS-Updates die ursprüngliche, ungepatchte Version von /etc/ssl/cert.pem wiederherstellen können, könnte ein gestern gesicherter Rechner heute nach einem routinemäßigen Systemupdate wieder verwundbar sein. Ohne kontinuierliche Überprüfung können Administratoren nicht sicher sein, in welchem Vertrauenszustand sich ihre Maschinen befinden. Diese Unsicherheit erschwert die Incident Response und Compliance-Audits, da zwei identisch aussehende Maschinen völlig unterschiedliche Sicherheitspositionen hinsichtlich der Zertifikatsvalidierung haben können.

Was Sie tun können

• Identifizieren Sie, welchen Zertifikatsspeicher Ihre kritischen Tools verwenden, indem Sie ausführliche Verbindungstests durchführen und nach CAfile- oder CApath-Ausgaben suchen.
• Vergleichen Sie die Ergebnisse von security verify-cert mit Ihren Befehlszeilentools, um Unstimmigkeiten bei Vertrauensentscheidungen zu erkennen.
• Wenn Sie /etc/ssl/cert.pem manuell patchen, protokollieren Sie den Datei-Hash und das Datum und überprüfen Sie es nach jedem macOS-Softwareupdate erneut.
• Erwägen Sie, Tools auf ein einzelnes, kontrolliertes Zertifikatsbündel zu verweisen, indem Sie Umgebungsvariablen wie CURL_CA_BUNDLE oder SSL_CERT_FILE verwenden.
• Überwachen Sie Ihre extern erreichbaren Dienste auf Gültigkeit und Ablaufdatum der Zertifikate, um sicherzustellen, dass Ihre eigene Infrastruktur sicher bleibt.
• Prüfen Sie sprachspezifische Zertifikatsbündel, wie Python’s certifi, und aktualisieren Sie diese unabhängig vom Betriebssystem.