Apple sperrt kompromittierte eMudhra-Zertifikate und leitet Admins bei der CLI-Bereinigung an

Apple hat eine Sicherheitsmaßnahme eingeleitet, um Zertifikate zu sperren, die von kompromittierten Zwischenzertifizierungsstellen (Intermediate Certification Authorities) von eMudhra ausgestellt wurden. Ab dem 19. Oktober 2026 begann das Unternehmen, diese Credentials automatisch auf seinen Geräten zu blockieren, und stellte gleichzeitig spezifische Schritte für die manuelle Bereinigung bereit, die sich an Systemadministratoren richten, welche auf Befehlszeilenschnittstellen angewiesen sind.

Was ist passiert?

Der Sicherheitsvorfall geht auf die Kompromittierung privater Schlüssel zurück, die acht Zwischenzertifizierungsstellen gehören, die von eMudhra betrieben werden. Während zwei dieser Stellen Code-Signing-Zertifikate ausgeben, denen Apple-Frameworks nicht vertrauen, geben die anderen sechs Transport Layer Security (TLS)-Zertifikate aus. Diese Unterscheidung ist kritisch, da ein Angreifer, der im Besitz dieser kompromittierten Schlüssel ist, gültig aussehende TLS-Zertifikate für jede Website generieren könnte. Dies ermöglicht potenziell Man-in-the-Middle-Angriffe oder die Identitätsfälschung legitimer Dienste.

Als Reaktion darauf haben sowohl eMudhra als auch Sectigo die betroffenen Zertifikate widerrufen. Der Umfang des Problems umfasst zwölf spezifische Zertifikate, die mit den sechs TLS-ausstellenden Intermediate CAs verbunden sind. Jede dieser sechs Stellen hält zwei Zertifikate: eines, das von emSign Root TLS CA - G3 ausgestellt wurde und zur emSign ECC Root CA - G3 führt, sowie ein weiteres, das von Sectigo cross-signiert wurde und zu AAA Certificate Services führt. Apple hat diese zwölf Zertifikate als primäre Vektoren für einen möglichen Missbrauch identifiziert und Maßnahmen ergriffen, sie in seinem gesamten Ökosystem zu neutralisieren.

Wichtige Details

• Apple begann am 19. Oktober 2026, die zwölf kompromittierten Zertifikate auf allen Apple-Geräten zu sperren.
• Die Sperre gilt automatisch für Safari, Mail und Apps, die Apples native Netzwerk- und Sicherheitsframeworks nutzen.
• Am 23. Oktober 2026 erweiterte Apple die Sperre auf das Root-Zertifikat emSign ECC Root CA - G3.
• Befehlszeilentools wie curl, git, python3, ruby, perl und openssl akzeptieren diese Zertifikate möglicherweise weiterhin, wenn sie sich auf die lokale Datei /etc/ssl/cert.pem verlassen.
• Apple wird ein zukünftiges Software-Update liefern, um die Schwachstelle bei den Befehlszeilentools zu beheben; für allgemeine Benutzer ist jedoch kein sofortiges OS-Update erforderlich.
• Administratoren können die kompromittierten Root-Zertifikate manuell aus /etc/ssl/cert.pem entfernen, um CLI-Workflows zu schützen, bevor der offizielle Patch eintrifft.

Hintergrund

Um die Auswirkungen zu verstehen, hilft es, zwischen den verschiedenen Methoden zu unterscheiden, wie Anwendungen auf macOS die Identität verifizieren. Die meisten verbraucherorientierten Apps, einschließlich Webbrowsern wie Safari, nutzen Apples zentralisierte Sicherheitsframeworks. Diese Frameworks erhalten aktualisierte Blocklisten über die Luft (Over-the-Air), sodass Apple das Vertrauen in kompromittierte Zertifikate sofort widerrufen kann, ohne dass ein vollständiges Betriebssystem-Update erforderlich ist. Dieser Mechanismus schützt die überwiegende Mehrheit der Benutzer automatisch.

Viele Entwicklungs- und Systemverwaltungstools arbeiten jedoch anders. Dienstprogramme wie curl und git umgehen oft Apples zentralen Trust Store und prüfen stattdessen gegen eine lokale Datei namens /etc/ssl/cert.pem. Diese Datei enthält ein Bündel vertrauenswürdiger Root-Zertifikate, die direkt auf der Festplatte gespeichert sind. Da diese Tools keine Live-Blockliste von Apple abfragen, bleiben sie gegenüber den kompromittierten eMudhra-Zertifikaten verwundbar, bis die lokale Datei entweder manuell von einem Administrator bearbeitet oder durch ein zukünftiges Software-Update von Apple ersetzt wird.

Warum ist das wichtig?

Für Teams, die ihre eigene Infrastruktur verwalten oder Software auf macOS entwickeln, stellt diese Lücke im automatischen Schutz ein greifbares Risiko dar. Wenn Ihre Deployment-Skripte, CI/CD-Pipelines oder Monitoring-Agenten Befehlszeilentools verwenden, um sich mit externen Diensten zu verbinden, könnten sie versehentlich einem böswilligen Server vertrauen, der ein gefälschtes Zertifikat präsentiert. Dies könnte zu Datenexfiltration oder zur Einschleusung von Schadcode während automatisierter Updates führen, da die Tools die Verbindung als sicher wahrnehmen würden.

Darüber hinaus erfordert der manuelle Bereinigungsprozess eine sorgfältige Ausführung. Das Bearbeiten systemweiter Zertifikatsspeicher ist eine sensible Operation. Das Entfernen des falschen Root-Zertifikats könnte die Konnektivität zu legitimen Diensten unterbrechen, die zufällig über dieselben Roots verlaufen. Administratoren müssen die Dringlichkeit der Schließung der Sicherheitslücke gegen die Notwendigkeit abwägen, die operative Stabilität aufrechtzuerhalten. Die Tatsache, dass Apple dies in einem zukünftigen Update beheben möchte, bedeutet, dass alle jetzt vorgenommenen manuellen Änderungen möglicherweise rückgängig gemacht oder sorgfältig verwaltet werden müssen, um Konflikte beim Eintreffen des offiziellen Patches zu vermeiden.

Was Sie tun können

• Überprüfen Sie, ob Ihr Workflow Terminal-basierte Tools wie curl, git oder python3 nutzt, die für die Zertifikatsvalidierung auf /etc/ssl/cert.pem angewiesen sind.
• Sichern Sie die aktuelle Zertifikatsdatei, indem Sie [ -e /etc/ssl/cert.pem.orig ] || sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.orig im Terminal ausführen.
• Entfernen Sie das emSign ECC Root CA - G3-Zertifikat aus dem lokalen Trust Store unter Verwendung des spezifischen awk-Befehls von Apple, um sicherzustellen, dass die Datei gültig bleibt.
• Entfernen Sie optional das AAA Certificate Services-Root-Zertifikat, wenn Sie die von Sectigo cross-signierten Zertifikate sofort blockieren müssen, wobei Sie beachten sollten, dass dies andere Dienste beeinträchtigen kann.
• Validieren Sie Ihre Änderungen, indem Sie den openssl-Verifizierungsbefehl ausführen, um zu bestätigen, dass die kompromittierten Roots nicht mehr in der Datei vorhanden sind.
• Beobachten Sie das kommende macOS-Software-Update, das /etc/ssl/cert.pem offiziell patchen wird, und stellen Sie das ursprüngliche Backup wieder her, falls das Update Ihre manuellen Bearbeitungen ersetzt.