Indische Regierungsseiten stellen widerrufene eMudhra-Zertifikate nach Massenwiderruf bereit

Ein erheblicher Vorfall im Zusammenhang mit der Zertifizierungsstelle eMudhra hat dazu geführt, dass Hunderte von Websites der indischen Regierung widerrufene digitale Zertifikate ausliefern. Das Problem trat Mitte Oktober 2026 auf, als private Schlüssel mehrerer Zwischenzertifizierungsstellen kompromittiert wurden, was dazu führte, dass die emSign ECC Root CA - G3 von großen Browsern wie Chrome und Mozilla nicht mehr vertraut wurde.

Was ist passiert?

Am 17. Oktober 2026 entdeckten Sicherheitsexperten, dass acht Zwischenzertifizierungsstellen von eMudhra, die zur emSign ECC Root CA - G3 gehören, private Schlüssel besaßen, die trivial wiederherstellbar waren. Diese Schlüssel wurden am folgenden Tag widerrufen. Als Reaktion darauf entzogen Mozilla und Chrome dem gesamten G3-Root-Zertifikat das Vertrauen. Separat widerrief eMudhra am 19. Oktober 9.356 Zertifikate in seiner nicht betroffenen RSA-Hierarchie, bekannt als emSign Root CA - G1. Der angegebene Grund für diesen Massenwiderruf war „Superseded“ (Ersetzt), was jedes nicht abgelaufene Zertifikat betraf, dem eine spezifische Policy-OID fehlte, die in den eigenen Zertifizierungspraxisrichtlinien von eMudhra vorgeschrieben war.

Das Ministerium für Elektronik und Informationstechnologie (MeitY) versuchte am 21. Oktober, die Schwere des Vorfalls herunterzuspielen. Ein Social-Media-Beitrag des Ministeriums behauptete, die Auswirkungen auf indische Websites seien sehr begrenzt und kurzlebig gewesen. Diese Einschätzung widerspricht technischen Beweisen, wonach die fehlerhaften Schlüssel bereits seit April 2025 existierten, was eine potenzielle Wiederherstellung über einen Zeitraum von achtzehn Monaten ermöglichte. Darüber hinaus hat das Widerrufsereignis weitreichende Störungen verursacht; eMudhra schätzt, dass 30.000 Zertifikate aus nicht betroffenen Zwischeninstanzen migriert werden müssen, wobei viele davon US-Universitäten und nicht indischen Einrichtungen gehören.

Trotz der offiziellen Entwarnung liefern indische Regierungsseiten auch Tage nach dem Ereignis noch widerrufene Zertifikate aus. Vier Behörden unter MeitY selbst, darunter die Controller of Certifying Authorities, die eMudhra reguliert, sind betroffen. Ein aktualisierter Scan vom 24. Oktober identifizierte 1.377 Domänennamen der indischen Regierung auf widerrufenen Zertifikaten, wobei 811 diese weiterhin aktiv auslieferten. Zu den betroffenen Diensten gehören Visa-Bearbeitung, Einwanderungsportale, Bürgerdienstplattformen wie ICEGATE und Bildungsressourcen.

Wichtige Details

• Acht Zwischen-CAs von eMudhra hatten wiederherstellbare private Schlüssel, die im April 2025 generiert wurden, was zu ihrem Widerruf am 18. Oktober 2026 führte.
• Am 19. Oktober 2026 widerrief eMudhra 9.356 Zertifikate in seiner RSA-Hierarchie aufgrund fehlender Policy-OIDs, was 2.976 Domänennamen der Regierung betraf.
• Stand 24. Oktober 2026 lieferten 811 Domänen der indischen Regierung weiterhin widerrufene Zertifikate aus, darunter kritische Dienste wie indianvisaonline.gov.in.
• Das Verhalten der Browser variiert erheblich: Firefox blockiert diese Seiten über CRLite, während Chrome, Edge und Safari den Zugriff oft gewähren, da ihre Widerrufslisten unvollständig sind.
• SSL Labs weist diesen Seiten die Note F zu und markiert sie als widerrufen, dennoch bleiben sie für viele Benutzer je nach Client-Software zugänglich.
• Die Controller of Certifying Authorities, die Regulierungsbehörde für eMudhra in Indien, liefert selbst ein widerrufenes eMudhra-Zertifikat auf ihrer PKI-Seite aus.

Hintergrund

Transport Layer Security (TLS)-Zertifikate verifizieren die Identität von Websites und verschlüsseln Daten während der Übertragung. Zertifizierungsstellen (CAs) wie eMudhra geben diese Zertifikate aus. Wenn eine CA eine Sicherheitsverletzung oder einen Konfigurationsfehler entdeckt, muss sie die betroffenen Zertifikate widerrufen. Der Widerruf informiert Browser darüber, dass ein zuvor vertrauenswürdiges Zertifikat nicht mehr gültig ist. Browser prüfen den Widerrufsstatus anhand von Mechanismen wie Certificate Revocation Lists (CRLs), Online Certificate Status Protocol (OCSP) oder kompakten Sätzen wie CRLite und CRLSet.

In diesem Fall entsteht die Inkonsistenz dadurch, dass verschiedene Browser unterschiedliche Methoden zur Prüfung des Widerrufs verwenden. Firefox nutzt CRLite, das alle Widerrufe abdeckt und den Zugriff sofort blockiert. Chrome verwendet CRLSet, das diese spezifischen Zertifikate Ende Oktober noch nicht enthalten hatte, wodurch Verbindungen fortgesetzt werden konnten. Diese Fragmentierung bedeutet, dass einige Benutzer Fehler sehen, während andere keine bemerken, was bei jenen, deren Browser den Widerruf nicht durchsetzen, ein falsches Sicherheitsgefühl erzeugt.

Warum es wichtig ist

Für Teams, die Self-Hosted-Software betreiben oder interne Infrastruktur verwalten, verdeutlicht dieser Vorfall die Fragilität, wenn man sich ausschließlich auf externe Zertifizierungsstellen ohne unabhängiges Monitoring verlässt. Wenn eine große CA ihre Abonnenten nicht benachrichtigt oder die Durchsetzung durch die Browser inkonsistent ist, können Ihre Dienste für manche Benutzer funktional erscheinen, während sie von anderen als unsicher eingestuft werden. Dies kann zu Risiken bei der Datenoffenlegung, Vertrauensverlust der Nutzer und Compliance-Verstößen führen, insbesondere bei Organisationen, die sensible Bürger- oder Kundendaten verarbeiten.

Die Verzögerung beim Ersetzen widerrufener Zertifikate zeigt zudem operative Lücken auf. Selbst wenn Widerrufe ausgesprochen werden, dauert die Migration von Tausenden von Zertifikaten Zeit und erfordert Koordination. Ohne automatische Warnmeldungen und Transparenz bezüglich des Zertifikatsstatus könnten IT-Teams unwissentlich bleiben, bis ihre Dienste beeinträchtigt sind und Benutzer Probleme melden. Für Regierungs- und Unternehmensentitäten kann diese Verzögerung kritische Dienste wie Visaanträge oder Steuererklärungen stören und reale Schäden verursachen.

Darüber hinaus unterstreicht die regulatorische Ironie, dass die Aufsichtsbehörde selbst ein widerrufenes Zertifikat ausliefert, die Notwendigkeit strenger interner Audits. Compliance bedeutet nicht nur, ein Zertifikat zu erhalten, sondern seine Gültigkeit über den gesamten Lebenszyklus hinweg aufrechtzuerhalten. Teams müssen davon ausgehen, dass externe Benachrichtigungen verzögert oder unvollständig sein können, weshalb proaktives Monitoring für die Aufrechterhaltung der Verfügbarkeit und der Sicherheitslage unerlässlich ist.

Was Sie tun können

• Implementieren Sie automatisiertes TLS-Zertifikatsmonitoring, das den Widerrufsstatus unabhängig vom Browserverhalten prüft, indem Tools verwendet werden, die CRLs und OCSP-Responder direkt abfragen.
• Richten Sie Warnmeldungen für Zertifikatsablauf und Widerrufsereignisse ein, um sicherzustellen, dass Ihr Team benachrichtigt wird, bevor Benutzer auf Verbindungsfehler stoßen.
• Auditieren Sie regelmäßig Ihr Zertifikatsinventar, um Zertifikate zu identifizieren, die von CAs stammen, die Sicherheitsvorfälle oder Ereignisse zum Entzug des Root-Vertrauens durchlaufen.
• Testen Sie Ihre Dienste über mehrere Browser und Geräte hinweg, um zu verstehen, wie unterschiedliche Mechanismen zur Widerrufsprüfung den Benutzerzugriff beeinflussen.
• Halten Sie einen Notfallplan für den schnellen Zertifikatsaustausch bereit, einschließlich vorconfigurierter Automatisierung für die Bereitstellung neuer Zertifikate von alternativen CAs, falls erforderlich.
• Überprüfen Sie Ihre Zertifizierungspraxisrichtlinien und stellen Sie sicher, dass Ihre Zertifikate alle erforderlichen Policy-OIDs enthalten, um Massenwiderrufe aufgrund von Compliance-Fehlern zu vermeiden.