DigiCerts Widerrufsfrist machte die Zertifikatsvalidierung zu einem Verfügbarkeitsverantwortungstest

Zusammenfassung

• DigiCert meldete in Mozilla Bugzilla, dass es einige Domains mithilfe eines Zufallswerts in einem CNAME-Eintrag ohne den erforderlichen Unterstrich-Präfix validiert hatte, was einen Pfad in seinem OEM-Validierungssystem betraf. Der Vorfallbericht besagte, dass 83.267 gültige TLS-Zertifikate auf dieser Grundlage ausgestellt wurden und die betroffene Menge wahrscheinlich zu hoch gegriffen war, da das System nicht ausreichend gespeichert hatte, ob der Unterstrich vorhanden war.
• Das Widerrufsproblem war unmittelbar. Die CA/Browser Forum TLS Baseline Requirements verlangen den Widerruf innerhalb festgelegter Zeitfenster für fehlerhaft ausgestellte Zertifikate, und DigiCerts Bericht über den verzögerten Widerruf besagt, dass es alle 83.267 betroffenen TLS-Zertifikate innerhalb von 120 Stunden widerrief, anstatt innerhalb des von den damaligen Regeln geforderten 24-Stunden-Zeitraums.
• Der Vorfall war nicht nur ein Programmierfehler einer Zertifizierungsstelle. Er offenbarte Schwächen im Zertifikatsbestand der Abonnenten, Kommunikationsgrenzen über Wiederverkäufer und Unternehmenskonten, rechtlichen Druck durch einen Rechtsstreit um eine einstweilige Verfügung eines Kunden und die Tatsache, dass vielen Organisationen noch die Automatisierung fehlte, um Zertifikate schnell in großem Umfang zu ersetzen.
• Die praktische Kontrolle war verteilt. DigiCert kontrollierte die Validierungsimplementierung, die Zertifikatsidentifikation, die Kundenbenachrichtigung, die Durchführung des Widerrufs und die Vorfallberichterstattung. Root-Programme und das CA/Browser Forum kontrollierten die Vertrauenserwartungen und den politischen Druck, nicht aber die Kundenbereitstellung. Abonnenten kontrollierten ihre Bestände, Automatisierung, Änderungsfenster und dienstspezifische Einführungen. Endnutzer trugen fast kein Risiko.
• Die Lektion in Bezug auf die Rechenschaftspflicht ist, dass Zertifizierungsstellen den Widerruf nicht als seltenen Verwaltungsakt betrachten können und Abonnenten öffentlich vertrauenswürdige TLS-Zertifikate nicht als statische Infrastruktur behandeln können. Das Sicherheitsmodell der Web-PKI hängt davon ab, dass der schnelle Austausch betrieblich alltäglich ist, bevor der Notfall eintritt.

Ein fehlender Unterstrich wurde zu einem globalen Kontinuitätsproblem

Der DigiCert-Vorfall ist leicht zu verharmlosen, wenn er auf Zeichensetzung reduziert wird. Das technische Problem betraf einen erforderlichen Unterstrich-Präfix in einem DNS-CNAME-basierten Pfad zur Domain-Controller-Validierung. Die Folge war jedoch keine typografische Korrektur. DigiCert musste Zehntausende öffentlich vertrauenswürdige Zertifikate identifizieren und widerrufen, die über Cloud-Dienste, Telekommunikationsnetze, Gesundheitsumgebungen, Unternehmensanwendungen und kundenorientierte Websites verteilt waren.

DigiCerts eigener öffentlicher Vorfallbericht im Mozilla Bugzilla bug 1910322 ist der faktische Anker. DigiCert berichtete, dass es einen Zertifikatsproblembericht erhalten hatte, der darauf hindeutete, dass es ein Problem mit der Implementierung von Methode 7, der DNS-basierten Validierung, geben könnte. Es beschrieb mehrere DNS-bezogene Verifizierungsprozesse und sagte, dass eine Code-Überprüfung einen Pfad fand, bei dem ein Zertifikat ausgestellt werden konnte, wenn der Zufallswert als Host in einem CNAME-Eintrag verwendet wurde, ohne zuerst einen Unterstrich voranzustellen.

Später im selben Bug sagte DigiCerts Vorfallbericht, dass die Auswirkungen auf Emittenten beschränkt waren, die sein OEM-Validierungssystem nutzten, während Validierungspfade über CertCentral und CIS, seine Hochvolumen-Ausstellungs-Engine für Cloud-Anbieter, Domains korrekt validierten und nicht betroffen waren.

Die Zahl stammt ebenfalls aus dem öffentlichen Vorfallbericht. DigiCert gab an, dass 83.267 gültige Zertifikate auf der Grundlage dieser Methode ausgestellt wurden und dass es alle gültigen Zertifikate in der Datenbank widerrufen würde, die als mit CNAME-basierter DNS-Validierung versehen aufgeführt waren, bevor der Fix durchgeführt wurde. Es erklärte, dass dies die tatsächliche Anzahl wahrscheinlich überstieg, da die OEM-Systemsteuerungen nicht ausreichend gespeichert hatten, ob ein Unterstrich vorhanden war. Dieser Satz ist der Dreh- und Angelpunkt der Rechenschaftspflicht.

Das System konnte eine Risikopopulation identifizieren, aber nicht sauber beweisen, welche Zertifikate die konforme Form hatten. In einem Vertrauenssystem kann Unsicherheit über die Einhaltung der Vorschriften zu einer Widerrufspflicht werden.

Der Sicherheitsgrund für den Unterstrich ist nicht nur ästhetisch. Die Validierungsmethoden des CA/Browser Forums unterscheiden zwischen Namen, die ein Abonnent kontrolliert, und Namen, die delegiert oder benutzergeneriert unter einer größeren Domain sein können. Die Diskussion in Bugzilla betonte, dass eine mit Unterstrich versehene Bezeichnung dazu beiträgt, einen speziellen Validierungsnamespace zu schaffen, den gewöhnliche Hostnamen und viele delegierte Subdomain-Dienste vermeiden können.

Ein fehlender Unterstrich kann eine Annahme untergraben, die verwendet wird, um unerwünschte Zertifikatsausstellungen zu verhindern, wenn Benutzer Subdomains unter einer Domain erstellen können, die sie nicht kontrollieren.

Deshalb gehört dieses Ereignis unter die DNS-Delegierungsbefugnis. Die Domain-Validierung ist eine Möglichkeit, Beweise aus dem DNS in die Befugnis zur Ausstellung eines Zertifikats umzuwandeln. Wenn die Beweise von der falschen Stelle akzeptiert werden oder wenn eine erforderliche Grenzmarkierung fehlt, kann die Zertifizierungsstelle eine schwächere DNS-Platzierung als Kontrollnachweis behandeln. Das Zertifikat gibt dann vertrauenden Parteien ein vom Browser vertrauenswürdiges Signal für einen Namen. Die Ausstellungsbefugnis ist daher mit der Fähigkeit verbunden, die DNS-Delegierung korrekt zu interpretieren.

Die Regeln taten, was Regeln tun: Sie zwangen zum Handeln

Die TLS Baseline Requirements des CA/Browser Forums sind die öffentlichen Regeln im Zentrum des Vorfalls. Sie definieren Domain-Validierungsmethoden und Zertifikatswiderrufspflichten für öffentlich vertrauenswürdige TLS-Serverzertifikate. Der Artikel muss nicht jede Anforderung zitieren, um die Rechenschaftsstruktur zu erklären: Wenn ein Zertifikat falsch ausgestellt wurde oder die Validierung nicht den Baseline Requirements entsprach, muss die Zertifizierungsstelle innerhalb der geltenden Frist widerrufen, es sei denn, die Regeln selbst erlauben einen anderen Weg.

DigiCerts Bericht über den verzögerten Widerruf in Mozilla Bugzilla bug 1910805 beschreibt den Compliance-Konflikt eindeutig. DigiCert erklärte, dass es daran gearbeitet habe, alle Zertifikate innerhalb von 24 Stunden zu widerrufen, sich aber nach Rücksprache mit den Root-Programmen und der Community über die Auswirkungen entschieden habe, den Widerruf zu verzögern und alle betroffenen Zertifikate innerhalb von 120 Stunden zu widerrufen. Sein späterer Vorfallbericht fasste die Auswirkungen zusammen: DigiCert widerrief 83.267 Zertifikate in fünf Tagen anstatt in 24 Stunden, wie es die damaligen Baseline Requirements vorschrieben.

Dieses Eingeständnis ist wichtig, weil es zwei Vorfälle trennt. Bug 1910322 betraf die Nichteinhaltung der Domain-Validierung. Bug 1910805 betraf den verzögerten Widerruf. Das erste Problem war, wie Zertifikate als nicht konform angesehen wurden. Das zweite Problem war, wie das Ökosystem mit der Verpflichtung umging, diese Zertifikate aus dem Vertrauensbereich zu entfernen, während Kunden sich für Live-Dienste auf sie verließen.

Die Unterscheidung verhindert ein oberflächliches Argument. Man könnte sagen, DigiCert hätte sofort widerrufen und sich an die Regel halten sollen. Das ist die saubere politische Position. Man könnte auch sagen, dass ein sofortiger Widerruf kritische Dienste gestört hätte und die Verzögerung daher praktisch war. Das ist die operative Position. Der Vorfall zeigt die unbequeme Kluft zwischen beiden. Die Regeln für das öffentliche Vertrauen sollen vertrauende Parteien vor ungültigen oder falsch ausgestellten Zertifikaten schützen.

In der realen Welt verhalten sich Abonnenten oft so, als ob Zertifikate schwer zu ersetzende Vermögenswerte wären, die an Wartungsfenster, Geräte, Lastenausgleicher, eingebettete Systeme und Änderungsgenehmigungen gebunden sind.

Root-Programme waren vorsichtig mit Autorität. Im Bugzilla-Thread sagten Vertreter des Chrome Root Program, dass sie nicht befugt seien, Ausnahmen von den CA/Browser Forum Baseline Requirements zu gewähren, und dass diese Anforderungen konsensbasiert seien und nicht von einem einzelnen Root-Programm kontrolliert würden. Die Chrome Root Program policy liefert den breiteren Browser-Root-Kontext: Eine Zertifizierungsstelle nimmt am Root-Store unter Programmerwartungen, Vorfallbewertung und kontinuierlichem Compliance-Druck teil.

Aber die Konsultation eines Root-Programms während einer Krise ist kein magischer Verzicht auf die öffentlichen Regeln.

Mozillas Root Store Policy und Mozillas CA incident response guidance erfüllen eine ähnliche Funktion. Sie machen die Vorfallberichterstattung und Reaktionsfähigkeit zu einem Teil der Vertrauensgovernance. Sie betreiben nicht die Server der Abonnenten und sie inventarisieren keine Zertifikate in der Kundeninfrastruktur. Sie schaffen das öffentliche Rechenschaftsforum, in dem DigiCert erklären musste, was passiert ist und was sich ändern würde.

DigiCerts Bericht war ungewöhnlich offen über organisatorische Ursachen

Der wertvollste Teil von DigiCerts Vorfallbericht war nicht die Zertifikatsanzahl. Es war die Sprache der Grundursache. DigiCert sagte, das Problem sei aufgetreten, als es Änderungen einführte, um Domain-Validierungsabläufe zu konsolidieren und Zufallswerte über mehrere Methoden hinweg wiederzuverwenden. Es sagte, dass ein Pfad durch das System den Unterstrich bei der CNAME-Überprüfung nicht enthielt. Es identifizierte Grundursachen wie die Abschottung zwischen Technik und Compliance, das Versäumnis, Zertifikatsproblemberichte ernst zu nehmen, wenn sie keine Seriennummern enthielten, und mangelnde technische Disziplin.

Diese Offenheit ist wichtig, weil Web-PKI-Vorfälle oft als enge Compliance-Mängel behandelt werden. Ein fehlendes Validierungspräfix kann als Code-Fehler beschrieben werden, aber DigiCerts eigener Bericht stellte es als systemisches Organisationsversagen dar. Compliance-kritische Technik kann nicht in einer eigenen Gedankenwelt getrennt von der Compliance-Interpretation arbeiten. Ein Zertifikatsproblembericht ohne Seriennummer kann dennoch eine echte Warnung sein. Ein Konsolidierungsprojekt kann Systeme verbessern, aber auch Fehler aufdecken, die von alten Arbeitsablaufgrenzen geerbt wurden.

Derselbe Bugzilla-Eintrag enthält die Anerkennung der DigiCert-Führung, dass interne Teams nicht immer so zusammenarbeiteten, wie sie sollten, und dass die Welt, die auf sie angewiesen ist, dies inakzeptabel machte. Das ist kein rechtliches Urteil, aber es ist ein starkes institutionelles Eingeständnis: Eine öffentlich vertrauenswürdige Zertifizierungsstelle ist nicht einfach ein weiterer SaaS-Anbieter. Ihr Validierungscode trifft Behauptungen, auf die Browser, Betriebssysteme, Websites, Behörden, Banken, Krankenhäuser und Benutzer vertrauen, ohne den internen Arbeitsablauf der Zertifizierungsstelle zu sehen.

DigiCert sagte auch, dass der betroffene Pfad auf das OEM-Validierungssystem beschränkt war, nicht auf CertCentral und CIS. Diese Grenze ist wichtig. Sie verhindert, dass der Vorfall als Versagen aller DigiCert-Validierungskanäle überbewertet wird. Aber die Grenze wirft auch eine Kontrollfrage auf: Warum hatte ein Validierungssystempfad ein unterschiedliches Compliance-Verhalten, und warum behielt das Datenmodell nicht genügend Details, um nachträglich zwischen konformen und nicht konformen Fällen zu unterscheiden?

Die Entscheidung zur Überzählung war verständlich. Wenn die Zertifizierungsstelle nicht feststellen kann, welche Zertifikate mit dem fehlenden Unterstrich ausgestellt wurden, ist der Widerruf aller Zertifikate in der Risikogruppe sicherer für das Vertrauen der vertrauenden Parteien, als möglicherweise nicht konforme Zertifikate am Leben zu lassen. Aber ein zu weitgehender Widerruf erhöht die Störung der Abonnenten und den Supportaufwand. Das sind die Kosten unzureichender forensischer Präzision in den Zertifikatsausstellungsdaten.

Die Lektion für Zertifizierungsstellen ist daher zweigeteilt. Erstens benötigen Validierungsimplementierungen eine rigorose Testabdeckung gegen die Baseline Requirements. Zweitens benötigen Ausstellungssysteme evidenzielle Aufzeichnungen, die detailliert genug sind, um eine präzise Korrektur zu unterstützen. Eine Zertifizierungsstelle sollte nicht zwischen unzureichendem Widerruf und massivem Überwiderruf wählen müssen, weil ihr eigenes System versagt hat, compliance-kritische Fakten zu bewahren.

Die Seite der Abonnenten verwandelte Richtlinien in Schmerz

DigiCerts erstes Bugzilla-Update besagte, dass 83.267 Zertifikate 6.807 Abonnenten betrafen. Es sagte auch, dass viele Kunden, die kritische Infrastruktur, lebenswichtige Telekommunikationsnetze, Cloud-Dienste und Gesundheitsbranchen betreiben, nicht in der Lage waren, ohne kritische Dienstunterbrechungen widerrufen zu werden. Diese Aussage war keine pauschale Ausnahme. Es war ein Beweis dafür, dass große Teile des Abonnenten-Ökosystems betrieblich nicht auf schnelle Ersatzbeschaffung vorbereitet waren.

Die CISA-Warnung zu DigiCert Certificate Revocations zeigt die Auswirkungen auf den öffentlichen Dienst. CISA sagte, dass DigiCert eine Teilmenge von TLS-Zertifikaten aufgrund eines Nicht-Compliance-Problems mit der Domain-Controller-Überprüfung widerrufe und warnte, dass der Widerruf vorübergehende Störungen von Websites, Diensten und Anwendungen verursachen könnte, die auf diese Zertifikate für sichere Kommunikation angewiesen sind. CISA forderte die Kunden auf, ihr DigiCert-Konto zu überprüfen und Zertifikate neu auszustellen oder zu erneuern. Das Update vom 31.

Juli verwies die Kunden auf aktualisierte Informationen und Fristen und ermutigte sie, DigiCert zu kontaktieren, wenn sie bis zur aktualisierten Widerrufsfrist keine Neuausstellung oder Erneuerung vornehmen konnten.

Die Incident-Seite von Google Cloud zum DigiCert-Widerrufsereignis ist nützlich, weil sie zeigt, wie ein CA-Ereignis zur Arbeit für Cloud-Kunden wird. Cloud-Anbieter haben den Validierungsfehler möglicherweise nicht verursacht, aber sie haben Kunden, deren Dienste, Lastverteiler, APIs, Gateways oder verwaltete Produkte von betroffenen Zertifikaten abhängen können. Wenn eine Zertifizierungsstelle in großem Umfang widerruft, müssen Zwischenhändler betroffene Vermögenswerte identifizieren, kommunizieren, Ersatzpfade bereitstellen und Ausfallzeiten reduzieren.

Für kleine und mittelständische Organisationen kann der Schmerz größer sein. Ein KMU kann ein Zertifikat in einem Hosting-Panel, einer Firewall, einem VPN-Gerät, einem Point-of-Sale-System, einem Mail-Gateway, einem Identitätsanbieter, einem API-Gateway, einem Mobile-App-Backend, einer SaaS-Integration oder einer anbieterverwalteten Plattform installiert haben. Die Person, die das Zertifikat bestellt hat, ist möglicherweise nicht mehr da. Der DNS-Validierungskontakt kann ein Wiederverkäufer sein. Das Zertifikat kann in einer Tabelle verfolgt werden oder gar nicht.

Der Ersatz kann eine Änderungsgenehmigung außerhalb der Geschäftszeiten oder ein Anbieterticket erfordern. Vierundzwanzig Stunden sind eine lange Zeit für ein Skript und eine kurze Zeit für eine fragile Organisation.

Deshalb passt die Bezeichnung „KMU-Servicekontinuität". Der Vorfall gefährdete die Verfügbarkeit durch eine Sicherheitskontrollkorrektur. Ein Zertifikat kann mathematisch klein und betrieblich zentral sein. Wenn es abläuft oder ohne Ersatz widerrufen wird, lehnen Browser und Clients Verbindungen ab, APIs fallen aus, Benutzer sehen Warnungen, und Dienste, die nie wie „Zertifikatsinfrastruktur" aussahen, werden unverfügbar.

Die Rechenschaftspflicht der Abonnenten ist real. Organisationen, die öffentliche Dienste betreiben, sollten wissen, welche Zertifikate sie haben, wo sie bereitgestellt sind, welche Zertifizierungsstelle sie ausgestellt hat, wann sie ablaufen, wie sie ersetzt werden, wer die Änderung genehmigt und ob Automatisierung existiert. Aber die Rechenschaftspflicht der Zertifizierungsstelle ist ebenfalls real. Eine Zertifizierungsstelle, die weiß, dass der Widerruf obligatorisch ist, sollte Validierung, Inventar, Benachrichtigung und Kundentools für den Notfallersatz entwerfen, nicht nur für gewöhnliche Erneuerungen.

Wiederverkäufer und Kundenkanäle waren Teil der Fehleroberfläche

Die Bugzilla-Diskussion umfasste Bedenken, dass Wiederverkäufer ihren Abonnenten möglicherweise keine Widerrufsinformationen zur Verfügung stellten und dass die reine E-Mail-Benachrichtigung Verwirrung stiftete. DigiCert erklärte später, dass es Nachrichten in der Konsole hinzugefügt habe, um Benutzer zu warnen, aber die Kommunikation außerhalb von E-Mails in kurzer Zeit sei schwierig gewesen. Dies ist ein praktisches Detail mit großen Konsequenzen.

Zertifizierungsstellen arbeiten oft über Kontenhierarchien, Wiederverkäufer, Enterprise-Procurement-Teams, Managed-Service-Provider und Cloud-Zwischenhändler. Der Abonnent, der den Live-Endpunkt kontrolliert, ist möglicherweise nicht der Kontoinhaber, der die E-Mails der Zertifizierungsstelle erhält. Ein Wiederverkäufer erhält möglicherweise eine Benachrichtigung und muss sie weiterleiten. Ein zentrales Sicherheitsteam besitzt möglicherweise das Zertifizierungsstellenkonto, während die Anwendungseigentümer die Bereitstellung besitzen. Ein verwalteter Dienst kann den privaten Schlüssel und das Zertifikat im Namen des Kunden halten.

Jede Übergabe verbraucht Zeit innerhalb eines 24-Stunden-Widerrufsfensters.

Dies macht die Widerrufskommunikation zu einer Kontrollaufgabe, nicht zu einer Höflichkeit. Notfallmeldungen sollten technische Kontakte, Kontokontakte, Wiederverkäuferkontakte und maschinenlesbare Endpunkte erreichen. Sie sollten betroffene Zertifikatsserien, Domains, Produkte, Ersatzschritte, Fristen und die Folgen von Untätigkeit identifizieren. Sie sollten über die Konsole, API, E-Mail und Statuskanäle verfügbar sein. Sie sollten es einem Abonnenten leicht machen, ein vollständiges betroffenes Inventar zu exportieren.

DigiCerts Revocation Incident Notice, die von der CISA und in der Mozilla-Diskussion verlinkt wurde, erfüllte die kundenorientierte Mitteilungsrolle. DigiCerts Statusportal unter status.digicert.com wurde von der CISA ebenfalls für aktualisierte Zeitpläne referenziert. Diese Seiten sind wichtig, selbst wenn der Archivzugriff unvollkommen ist, weil öffentliche Behörden und Root-Programm-Diskussionen Kunden während des Vorfalls darauf verwiesen.

Die Kommunikation musste auch vermeiden, eine falsche Zusage zu schaffen, dass der Widerruf optional sei. Ein Bugzilla-Teilnehmer kritisierte die Idee von Kundenanträgen auf Verzögerung, da dies andeuten könnte, dass der obligatorische Widerruf verhandelbar sei. DigiCert selbst erklärte später, dass es kein Verzögerungsantragsformular erstellen wolle, da verzögerte Widerrufe nicht erlaubt seien und ein solches Formular vermitteln könnte, dass sie zulässig seien. Diese Spannung ist real.

Eine Zertifizierungsstelle muss über das Risiko kritischer Infrastruktur informiert werden, aber die Regel besteht darin, vertrauende Parteien zu schützen, die nicht an der privaten Unterhaltung teilnehmen.

Die bessere Antwort ist nicht Schweigen. Es ist eine vorbereitete, richtlinienkonforme Kommunikation. Abonnenten sollten im Voraus wissen, dass die Zertifizierungsstelle ohne längere Verhandlungen widerrufen kann. Sie sollten über Automatisierung verfügen, um schnell zu ersetzen. Zertifizierungsstellen sollten genaue Bestände und mehrkanalige Benachrichtigungen haben. Root-Programme sollten die öffentliche Vorfall-Diskussion sichtbar genug halten, dass außergewöhnliche Behauptungen nicht zu privaten Absprachen werden.

Rechtlicher Druck offenbarte die schwache Kante des obligatorischen Widerrufs

Der Bericht über den verzögerten Widerruf besagt, dass DigiCert eine Mitteilung erhielt, dass ein Kunde eine einstweilige Verfügung gegen den Widerruf beantragt hatte. Das öffentliche Dossier, Alegeus Technologies LLC v. DigiCert, ist Teil des Vorfallberichts, weil es zeigt, wie der Druck der Abonnentenkontinuität mit den Verpflichtungen der Zertifizierungsstelle kollidieren kann. Spätere Bugzilla-Kommentare besagten, dass die rechtlichen Probleme zwischen den Parteien beigelegt wurden.

Der Rechtsstreit sollte nicht überinterpretiert werden. Eine vorläufige gerichtliche Einreichung ist kein endgültiges Urteil darüber, dass DigiCert recht oder unrecht hatte oder dass der Kunde ein dauerhaftes Recht hatte, den Widerruf zu blockieren. Es ist ein Beweis für Druck während des Vorfalls. Ein Abonnent, der mit Ausfallzeiten konfrontiert ist, kann zu rechtlichen Mitteln greifen, wenn er glaubt, dass der Widerruf Schaden verursacht.

Eine Zertifizierungsstelle, die ihren Verpflichtungen gegenüber den Root-Programmen nachkommt, muss möglicherweise ihre Befugnis zum Widerruf gemäß den Abonnementverträgen und den Regeln des öffentlichen Vertrauens verteidigen.

Dies ist ein strukturelles Problem für die Web-PKI. Vertrauende Parteien auf der ganzen Welt sind darauf angewiesen, dass Zertifizierungsstellen falsch ausgestellte Zertifikate rechtzeitig widerrufen. Ein einzelner Abonnent ist darauf angewiesen, dass seine eigenen Dienste betriebsbereit bleiben. Gerichte, Verträge und Notfallmeldungen können lokal sein, während das Browser-Vertrauen global ist. Wenn eine Zertifizierungsstelle verzögert, weil ein Abonnent rechtliche Erleichterung erhalten hat, ist das Risiko nicht auf diesen Abonnenten beschränkt. Es wird Teil des öffentlichen Vertrauensprotokolls.

Abonnementverträge und Unternehmensverträge sollten daher eindeutig sein. Eine Zertifizierungsstelle muss das Recht behalten, Zertifikate zu widerrufen, wenn dies von den Baseline Requirements oder der Root-Programm-Richtlinie gefordert wird. Kunden sollten wissen, dass betriebliche Unannehmlichkeiten keine Garantie für Verzögerung sind. Gleichzeitig sollten Zertifizierungsstellen Kundenprogramme so gestalten, dass ein Notfallwiderruf nicht als Überraschung kommt, nachdem Zertifikate jahrelang als manuelle Vermögenswerte behandelt wurden.

Der Vorfall deutet auch darauf hin, dass rechtliche Bereitschaft Teil der Vorfallbereitschaft einer Zertifizierungsstelle ist. Eine Zertifizierungsstelle sollte vor dem nächsten Massenwiderruf wissen, wer Anträge auf einstweilige Verfügungen prüfen kann, wie Abonnementverträge den obligatorischen Widerruf unterstützen, welche öffentlichen Aussagen gemacht werden können und wie man sich mit Root-Programmen abstimmt, ohne sie um Autorität zu bitten, die sie nicht haben. Die Uhr ist zu kurz für Improvisation.

Automatisierung war die fehlende Widerstandsfähigkeitsschicht

Der Bug zum verzögerten Widerruf enthält die klarste Aussage des gesamten Vorfalls: Nach Abschluss des Widerrufs sagte DigiCert, der Hauptgrund, warum Organisationen nicht innerhalb von 24 Stunden ersetzen konnten, sei, dass die überwiegende Mehrheit der Organisationen in der Branche noch keine Automatisierung zur Ausstellung, Verwaltung und Ersetzung von Zertifikaten einsetzte. Das ist die betriebliche Lektion.

ACME, definiert in RFC 8555, wurde entwickelt, um die Zertifikatsausstellung und -verwaltung zu automatisieren. Automatisierung ist nicht auf ACME beschränkt und nicht jedes Unternehmenssystem ist ACME-fähig. Aber das Prinzip ist breiter: Zertifikate sollten durch getestete Arbeitsabläufe erneuerbar und ersetzbar sein, nicht durch einmal jährliche manuelle Rituale. Der SC-063-Wahlgang des CA/Browser Forums zu kurzlebigen Zertifikaten und Automatisierungsanreizen zeigt, dass die Branche bereits vor diesem Vorfall auf kürzere Laufzeiten und bessere Agilität gedrängt hatte.

Die Bugzilla-Kommentare des Chrome Root Program machten denselben Punkt. Chrome-Vertreter sagten, sie priorisieren die Verbesserung von Agilität und Widerstandsfähigkeit in der gesamten Web-PKI, damit Widerrufsereignisse weniger störend sind, und sie stellten fest, dass Automatisierung und ARI-ähnliche Ansätze ohne breite Einführung durch Zertifizierungsstellen und Abonnenten nur begrenzten Nutzen haben. Der ACME Renewal Information extension draft ist relevant, weil er darauf abzielt, dass Zertifizierungsstellen Erneuerungszeitinformationen an ACME-Clients signalisieren können.

Es ist keine vollständige Lösung für alle Probleme des verzögerten Widerrufs, aber es spiegelt die richtige Richtung wider: maschinenlesbare Erneuerungs- und Ersatzkoordination.

Automatisierung ist auch für das Inventar wichtig. Ein Abonnent kann nicht ersetzen, was er nicht finden kann. Das Zertifikatsmanagement sollte grundlegende Fragen schnell beantworten: Welche Zertifikate führen zu DigiCert, welche sind von einem CA-Vorfall betroffen, welche Systeme verwenden sie, welche privaten Schlüssel sind verfügbar, welche Eigentümer sind verantwortlich, welche Ersatzbeschaffungen wurden bereitgestellt und welche Endpunkte bedienen immer noch widerrufene oder alte Zertifikate? Viele Organisationen entdecken in Notfällen, dass ihr Zertifikatsinventar nur Wunschdenken ist.

Für Zertifizierungsstellen muss die Automatisierung die Erkennung betroffener Zertifikate und die Kundenbenachrichtigung umfassen. In Bugzilla stellte die DigiCert-Diskussion fest, dass die Sammlung von Zertifikats- und Kontaktinformationen ein zentrales Data Lake und das Business-Intelligence-Team umfasste. Dieses Detail sollte jede Zertifizierungsstelle beunruhigen. Wenn ein Team außerhalb der normalen Vorfallreaktion benötigt wird, um eine Liste innerhalb einer 24-Stunden-Frist zusammenzustellen, ist der Prozess nicht ausreichend operationalisiert. Die für den Widerruf benötigten Daten sollten vorfallbereit sein.

Automatisierung ist kein Weg, um Rechenschaftspflicht zu vermeiden. Sie ist das Mittel, durch das Rechenschaftspflicht im Internet-Maßstab möglich wird. Regeln, die einen schnellen Widerruf verlangen, sind nur glaubwürdig, wenn Zertifizierungsstellen und Abonnenten einen schnellen Austausch ohne jedes Mal heroischen manuellen Aufwand durchführen können.

Der Ersatzarbeitsablauf muss auch die Erfolgsvalidierung umfassen. Ein Abonnent sollte ein neu heruntergeladenes Zertifikat nicht als Ende des Vorfalls betrachten. Er muss bestätigen, dass das Zertifikat auf jedem Endpunkt installiert ist, dass die Zwischenketten korrekt sind, dass alte Zertifikate nicht von sekundären Lastverteilern oder Notfallwiederherstellungsstandorten bedient werden, dass die Überwachung die widerrufene Seriennummer nicht mehr sieht und dass abhängige Clients den Ersatz akzeptieren. In einer großen Umgebung erfordern diese Überprüfungen Scannen und Service-Owner-Bestätigung, keinen einzigen Screenshot der Konsole.

DigiCerts Vorfall zeigte, warum Zertifikatsagilität eine Lebenszyklusdisziplin ist: erkennen, ausstellen, bereitstellen, verifizieren, überwachen und zurückziehen. Wenn einer dieser Schritte fehlt, kann aus einer CA-Compliance-Korrektur eine anhaltende Kundenausfallzeit werden.

Die gleiche Lektion gilt für die Managementaufsicht. Der Zertifikatsersatz sollte als Resilienzübung geprobt werden, nicht als ruhige Erneuerungsaufgabe behandelt, die von einem einzelnen Infrastrukturbesitzer erledigt wird. Vorstände und Risikoausschüsse müssen nicht jede Seriennummer überprüfen, aber sie sollten wissen, ob kritische öffentliche Dienste Zertifikate außerhalb der jährlichen Erneuerungssaison ersetzen können, ob Ausnahmeanträge schnell die Rechts- und Betriebsteams erreichen und ob die Organisation den Abschluss nachweisen kann, bevor der Widerruf die Benutzer erreicht.

In diesem Sinne war die DigiCert-Episode auch eine Planspielübung, die viele Abonnenten erst entdeckten, nachdem die Uhr bereits zu ticken begonnen hatte.

Die betroffenen Zertifikate waren ein Vertrauensproblem, aber nicht unbedingt ein Ausbeutungsbefund

Die öffentlichen Aufzeichnungen unterstützen einen Befund von nicht konformer Validierung und Massenwiderruf. Sie unterstützen aus den hier verwendeten Quellen keinen breiten Befund, dass Angreifer den DigiCert-Fehler ausgenutzt haben, um Zertifikate für große Dienste zu erhalten. Bugzilla-Teilnehmer fragten, ob DigiCert auf Ausbeutung geprüft habe, und diskutierten mögliche Risikoszenarien mit Diensten, die es Benutzern erlauben, beliebige Subdomains zu erstellen. Diese Fragen waren wichtig, aber Fragen sind keine Befunde.

Diese Grenze ist wichtig. Eine Überbewertung der Ausbeutung wäre unverantwortlich. Eine Unterbewertung des Risikos wäre ebenfalls falsch. Der Zweck der Domain-Controller-Validierung ist es, die Ausstellung an Parteien zu verhindern, die die betreffende Domain nicht kontrollieren. Wenn eine Validierungsmethode eine erforderliche Grenze lockert, muss die Zertifizierungsstelle Zertifikate, die über diesen Pfad ausgestellt wurden, als verdächtig behandeln, selbst wenn kein bekannter Angreifer sie genutzt hat.

Das öffentliche Vertrauen hängt von der Einhaltung der Regeln ab, gerade weil vertrauende Parteien nicht jeden Ausstellungsvorgang untersuchen können.

Die CCADB-Website bietet Kontext für die Transparenzinfrastruktur, die von Root-Stores und Zertifizierungsstellen verwendet wird, während crt.sh und Certificate Transparency Logs der Community helfen, ausgestellte Zertifikate zu überprüfen. Im Bugzilla-Thread analysierten Community-Mitglieder von DigiCert bereitgestellte Zertifikatslisten anhand von Certificate-Transparency-Daten. Dies ist eine Stärke der Web-PKI: Es gibt öffentliche Beweise für externe Überprüfungen. Es ist auch eine Erinnerung daran, dass Transparenz nach der Ausstellung nicht die korrekte Validierung vor der Ausstellung ersetzt.

Der Vorfallbericht besagte, dass DigiCert alle Zertifikate in der Risikogruppe widerrufen würde, auch wenn die Gruppe wahrscheinlich überzählt war. Das ist eine konservative Vertrauensentscheidung. Aber konservative Vertrauensentscheidungen verursachen Verfügbarkeitskosten. Die Web-PKI muss daher auf beiden Seiten investieren: Fehlausstellungen durch bessere Validierungskontrollen reduzieren und Störungen durch bessere Ersatzautomatisierung reduzieren.

Die Unterscheidung ist auch für Endbenutzer wichtig. Ein Browser-Benutzer, der eine Warnung über ein widerrufenes Zertifikat sieht, weiß nicht, ob das zugrunde liegende Zertifikat aktiv missbraucht wurde, über einen nicht konformen Pfad ausgestellt wurde oder von einer konservativen Überzählung erfasst wurde. Der Benutzer sieht nur ein Dienstproblem. Deshalb darf die Rechenschaftspflicht nicht beim Widerruf enden. Sie muss Kundenkommunikation und schnelle Abhilfe umfassen, damit das Sicherheitssignal aussagekräftig bleibt und nicht zu einem weiteren Grund wird, dass Benutzer Warnungen ignorieren.

Root-Programme waren Aufseher, nicht Betreiber der Kundenverfügbarkeit

Die Root-Programme von Mozilla, Chrome, Apple und Microsoft gestalten das öffentlich vertrauenswürdige CA-Ökosystem. Mozillas Root Store Policy, Chromes Root Program policy, Apples Certificate Transparency and trusted certificates program information und Microsofts Trusted Root Program requirements helfen alle, das Vertrauensumfeld zu definieren, in dem Zertifizierungsstellen arbeiten. Die spezifischen Richtlinien unterscheiden sich, aber die gemeinsame Idee ist, dass die Aufnahme in den Root-Store an vertrauenswürdiges CA-Verhalten geknüpft ist.

Der DigiCert-Vorfall zeigt die Grenzen dieser Aufsicht. Root-Programme können Berichte anfordern, Muster bewerten, einer Zertifizierungsstelle misstrauen, Maßnahmen verlangen und branchenweite Verbesserungen vorantreiben. Sie können keine Krankenhauszertifikate neu bereitstellen, keine Telekommunikations-Lastverteiler aktualisieren, keinen Kunden-Change-Management-Prozess umschreiben oder einen Wiederverkäufer dazu bringen, Benachrichtigungen sofort weiterzuleiten. Die Arbeit zur Vermeidung von Ausfällen ist verteilt.

Das macht Root-Programme nicht passiv. Ihre öffentlichen Bugzilla-Kommentare waren wichtig, weil sie sich privaten Ausnahmeregelungen widersetzten und den Druck auf die Baseline Requirements aufrechterhielten. Chromes Kommentar, dass es nicht befugt sei, Ausnahmen zu gewähren, ist eine Rechenschaftsaussage. Mozillas spätere Diskussion über die Überarbeitung der Richtlinie zum verzögerten Widerruf zeigte, dass der Vorfall in die Root-Programm-Governance zurückfließen kann. Öffentliche Root-Programm-Foren sind der Ort, an dem CA-Erklärungen von mehr als nur dem betroffenen Kunden und der Zertifizierungsstelle überprüft werden können.

Das CA/Browser Forum ist eine weitere Ebene. Das Forum schreibt die Baseline Requirements durch Konsens zwischen Zertifizierungsstellen und Browsern. Die TLS Baseline Requirements page ist daher kein externes Statut, das nur DigiCert auferlegt wurde. DigiCert und andere Zertifizierungsstellen sind am Ökosystem beteiligt, das die Verpflichtungen schafft. Wenn eine Zertifizierungsstelle die Verpflichtung später als betrieblich schmerzhaft empfindet, ist das ein Signal, die Agilität des Ökosystems zu verbessern, kein Beweis dafür, dass die Verpflichtung willkürlich ist.

Die schwierigste Governance-Frage ist, ob Widerrufsfristen für geringfügige Nichteinhaltung und hohes Verfügbarkeitsrisiko flexibler sein sollten. Vernünftige Leute in der Web-PKI-Community sind sich uneinig. Dieser Artikel löst diese politische Debatte nicht. Er identifiziert die Rechenschafts-Tatsache: Zum Zeitpunkt des Vorfalls erkannte DigiCert eine 24-Stunden-Anforderung an und schloss den Widerruf dann über 120 Stunden ab. Diese Diskrepanz ist ein Ereignis des öffentlichen Vertrauens.

Was DigiCert kontrollierte und was Abonnenten kontrollierten

DigiCert kontrollierte den Validierungscodepfad, den Technik- und Compliance-Überprüfungsprozess, die Reaktion auf den Zertifikatsproblembericht, den Fix, den Identifikationsprozess für betroffene Zertifikate, die Kundenbenachrichtigung, den öffentlichen Vorfallbericht, die Durchführung des Widerrufs und die Follow-up-Maßnahmen. Es kontrollierte auch, ob seine Systeme genügend Daten speicherten, um genau zu unterscheiden, welche Validierungen einen konformen Unterstrich verwendeten. In den öffentlichen Aufzeichnungen fehlte diese Datenpräzision.

DigiCert kontrollierte nicht die Zertifikatsbereitstellung jedes Abonnenten. Es kontrollierte nicht jede Wiederverkäuferübergabe, jedes Enterprise-Change-Board, jede Geräteeinschränkung, jede Architektur eines Cloud-Kunden oder jedes Wartungsfenster eines Krankenhauses. Es kontrollierte auch nicht allein die Baseline Requirements. Es war rechenschaftspflichtig für deren Einhaltung und für die Erklärung, wenn es sie nicht einhielt.

Abonnenten kontrollierten Inventar, Eigentum, Automatisierung, Bereitstellungsarchitektur, Erneuerungstests, Anbietereskalation und Change-Management-Bereitschaft. Ein Abonnent, der ein öffentliches TLS-Zertifikat nicht innerhalb eines Tages ersetzen kann, hat ein Verfügbarkeitsrisiko, unabhängig davon, ob der unmittelbare Auslöser DigiCerts Fehler ist. Der nächste Auslöser könnte ein Schlüsselkompromiss, eine Richtlinie für kurzlebige Zertifikate, ein Notfall-Misstrauensereignis, ein privater Schlüsselverlust oder ein Ablauffehler sein.

Wiederverkäufer und Managed-Service-Anbieter kontrollierten die Übergabe zwischen CA-Benachrichtigung und Endpunktbetreibern. Wenn sie Benachrichtigungen erhielten, aber nicht weiterleiteten oder sie nicht Live-Systemen zuordnen konnten, wurden sie Teil der Ausfalloberfläche. Cloud-Anbieter kontrollierten verwaltete Zertifikatsschichten und die Kundenkommunikation für die von ihnen betriebenen Dienste. Öffentliche Behörden wie die CISA kontrollierten die öffentliche Warnung und Kundenberatung, nicht die Systeme der Zertifizierungsstelle.

Endnutzer kontrollierten fast nichts. Sie waren darauf angewiesen, dass Browser und Clients das Zertifikatsvertrauen durchsetzen, dass Zertifizierungsstellen korrekt validieren, dass Dienstanbieter Zertifikate ersetzen und dass Root-Programme Zertifizierungsstellen zur Rechenschaft ziehen. Wenn ein Zertifikat widerrufen wurde und ein Dienst ausfiel, hatte der Benutzer die Wahl, den Dienst nicht mehr zu nutzen, das Risiko zu akzeptieren, wenn ein Client eine Umgehung erlaubte, oder zu warten. Diese Asymmetrie ist der Grund, warum die Last bei den Institutionen liegt.

Bessere Beweise und Kontrollen für den nächsten Vorfall

Ein besserer Satz von Kontrollen nach einem Vorfall beginnt beim Validierungsdesign. Jede Zertifizierungsstelle sollte ausführbare Tests unterhalten, die direkt jeder Baseline Requirements-Validierungsmethode zugeordnet sind, die sie unterstützt. Wenn der Wortlaut der Methode eine mit Unterstrich versehene Bezeichnung erfordert, sollte der Test ohne diese fehlschlagen. Wenn mehrere Produkte oder OEM-Systeme dieselbe Methode implementieren, sollten Sie eine gemeinsam genutzte, compliance-geprüfte Validierungsbibliothek verwenden oder ein gleichwertiges Verhalten nachweisen.

DigiCerts spätere Veröffentlichung von Domain-Control-Validation-Code unter github.com/digicert/domain-control-validation, mit Paketinformationen auf Maven Central und Dokumentation unter javadoc.io, ist hier relevant. Offenes Implementierungsmaterial kann Kunden und der Community helfen, das Validierungsverhalten zu verstehen, obwohl offener Code allein nicht die Produktionskonfiguration beweist oder organisatorische Risiken beseitigt.

Zweitens sollten Ausstellungsaufzeichnungen compliance-kritische Fakten bewahren. Eine Zertifizierungsstelle sollte für jedes gültige Zertifikat beantworten können, welche Validierungsmethode verwendet wurde, welcher Systempfad sie durchgeführt hat, welcher DNS-Eintrag beobachtet wurde, ob erforderliche Präfixe vorhanden waren, wann die Validierung stattfand, welches Konto oder welcher Wiederverkäufer beteiligt war und welche Zertifikate auf dieser Validierung beruhten. Diese Informationen sollten unter Incident-Druck abfragbar sein, ohne improvisierte Business-Intelligence-Arbeit.

Drittens sollte die Widerrufskommunikation maschinenlesbar sein. Abonnenten sollten betroffene Serien und Ersatzanforderungen über APIs, Dashboards und Automatisierungshooks abrufen können. E-Mail ist notwendig, aber unzureichend. Konsolenbanner helfen, können aber Betreiber übersehen, die sich nicht täglich anmelden. Wiederverkäufer sollten vertragliche Pflichten und technische Mechanismen haben, um Benachrichtigungen schnell weiterzuleiten.

Viertens sollten Abonnenten eine Zertifikatsstückliste führen. Diese sollte öffentliche und private Zertifikatsstandorte, Erneuerungseigentümer, Automatisierungsstatus, Schlüsselspeicher, abhängige Dienste, Ersatz-Runbooks und Notfallkontakte enthalten. Zertifikatsbestände sollten getestet werden, indem Zertifikate außerhalb der jährlichen Erneuerungssaison ersetzt werden. Ein Runbook, das noch nie ein Zertifikat unter Druck ersetzt hat, ist nur eine Hoffnung.

Fünftens sollten Root-Programme und das CA/Browser Forum die öffentliche Diskussion über verzögerten Widerruf fortsetzen, ohne dass private Ausnahmekultur zur Normalität wird. Wenn sich die Regeln weiterentwickeln, sollten sie transparent weiterentwickelt werden. Wenn sie sich nicht weiterentwickeln, müssen Zertifizierungsstellen und Abonnenten ihre Abläufe so gestalten, dass sie sie erfüllen.

Die bleibende Lektion

DigiCerts Widerrufsvorfall von 2024 ist eine kompakte Lektion darüber, wie Vertrauen und Betriebszeit kollidieren. Ein Validierungspfad verpasste einen erforderlichen Unterstrich. Die Zertifizierungsstelle konnte nicht genau zwischen jedem konformen und nicht konformen Fall trennen. Die Regeln verlangten einen schnellen Widerruf. Den Kunden fehlte es an ausreichender Automatisierung. Einige Betreiber kritischer Dienste waren mit Störungen konfrontiert. Eine rechtliche Herausforderung tauchte auf. Root-Programme wurden konsultiert, konnten die Regeln aber nicht aufheben. Die CISA warnte die Öffentlichkeit.

DigiCert widerrief schließlich die betroffenen TLS-Zertifikate über fünf Tage und erkannte organisatorische Ursachen an.

Die Angreifer in dieser Geschichte sind, falls es sie gab, nicht der Punkt der öffentlichen Aufzeichnung. Die Aufzeichnung handelt von institutioneller Kontrolle. DigiCert kontrollierte Validierung und Widerruf. Root-Programme kontrollierten die Vertrauensaufsicht. Abonnenten kontrollierten die Bereitstellungsbereitschaft. Wiederverkäufer und Cloud-Anbieter kontrollierten Kommunikationswege. Benutzer trugen die Konsequenzen.

Der praktische Standard ist klar. Eine Zertifizierungsstelle sollte nachweisen können, dass jede unterstützte Validierungsmethode genau wie erforderlich implementiert ist, dass Zertifikatsaufzeichnungen genügend Details für eine präzise Korrektur aufbewahren und dass der Notfallwiderruf ohne heldenhafte Datensammlung durchgeführt werden kann. Abonnenten sollten öffentliche Zertifikate schnell, wiederholt und durch Automatisierung ersetzen können. Root-Programme sollten die Vorfallberichterstattung öffentlich genug halten, dass Vertrauensentscheidungen sichtbar sind.

Die Glaubwürdigkeit der Web-PKI hängt von dem unbequemen Teil der Regel ab: falsch ausgestellte oder nicht konforme Zertifikate müssen das Vertrauen schnell verlassen, auch wenn das betrieblich schmerzhaft ist. Die Antwort ist nicht, so zu tun, als ob Widerruf immer schmerzfrei wäre. Die Antwort ist, den Zertifikatsbetrieb so aufzubauen, dass der nächste obligatorische Widerruf ein kontrollierter Wartungsarbeitsablauf ist, kein globales Chaos um eine Frist herum.