Zusammenfassung

  • Eine Root-Entfernung, ein Distrust-Stichtag oder eine Browser-Version ändert die beabsichtigte Regel; sie beweist nicht, dass jedes System, jede Anwendung, jeder Container und jedes eingebettete Validierungssystem sie durchsetzt.
  • Die Änderung ist als Migration der vertrauenden Systeme zu führen, mit Ablehnungstests je Vertrauensquelle und Client-Kohorte statt einer Zählung aktualisierter Geräte.

In einem kontrollierten hypothetischen Validierungsszenario lehnt eine aktuelle Chrome-Kohorte eine TLS-Kette ab, während ein unternehmensverwalteter Windows-Client und ein Dienst in einem alten Container-Image sie akzeptieren. Das Zertifikat ist in allen drei hypothetischen Tests identisch.

Das ist keine Randfrage der Syntax. Es ist die Karte dreier verschiedener Vertrauensentscheidungen.

2024 kündigte Chrome einen gezielten Vertrauensentzug für bestimmte Entrust-Roots an. Die Regel hing vom Datum des frühesten Signed Certificate Timestamp ab: Zertifikate nach dem veröffentlichten Stichtag wurden ab Chrome 131 standardmäßig nicht mehr akzeptiert, frühere Zertifikate anders behandelt. Es war keine einzelne Datei, die alle Clients gleichzeitig löschen und gleich auslegen, sondern eine Annahmeregel mit Wirksamkeitsdatum, Browserversion und Raum für ausdrücklich vertraute lokale Roots.

Chromes Architektur macht die Flottenfrage sichtbar. Unter Windows, macOS, ChromeOS, Linux und Android setzt Chrome zunehmend auf einen eigenen Root Store und eine integrierte Zertifikatsprüfung. Chrome auf iOS bleibt den Plattformregeln von Apple unterworfen. Eine Unternehmensrichtlinie erlaubte vorübergehend die Wahl zwischen Chrome Root Store und der Prüfung durch die Plattform; außerdem kann Chrome lokale Roots einbeziehen, denen das Betriebssystem ausdrücklich vertraut. Der Browsername bezeichnet daher nicht die gesamte Vertrauensquelle.

Microsoft zeigt eine zweite Abweichung. Die Dokumentation unterscheidet Removal, EKU Removal, Disallow, Disable und NotBefore. Die Entfernung aus der vertrauenswürdigen CTL macht Ketten standardmäßig unvertrauenswürdig, doch in manchen Stores kann der Root weiterhin manuell installiert werden. Disallow ist stärker: Das Zertifikat landet in der gesperrten CTL und manuelle Installation stellt das Vertrauen nicht einfach wieder her. Disable und NotBefore haben eigene zeitliche und funktionale Regeln.

Diese Zustände werden über ein Updatesystem verteilt. Verbundene Windows-Clients können vertrauenswürdige und gesperrte CTLs automatisch beziehen. Eine isolierte Umgebung kann dasselbe Material auf einen internen Datei- oder Webserver umleiten. Microsoft beschreibt getrennte Prüfungen für AuthRoot, Disallowed und den letzten Synchronisationszeitpunkt. Eine auf dem Server vorhandene Richtlinie beweist nicht, dass der Client sie übernommen hat.

Apple veröffentlicht einen aktuellen gemeinsamen Root Store und archiviert frühere Versionen. Die installierte Store-Version wird damit zu einem betrieblichen Nachweis. Sie warnt zugleich davor, ein älteres Gerät mit der aktuellen Webliste gleichzusetzen. Mozilla unterscheidet ebenfalls zwischen dem Abschalten von Trust Bits und der Entfernung des Zertifikats, kann beide Maßnahmen terminieren und erlaubt abgeleiteten Distributionen eine andere Auswahl.

Die Maßnahme vor der Messung benennen

„Root entfernen“ ist für eine Einsatzanweisung zu ungenau. Gemeint sein kann, alle Ketten abzulehnen, nur Zertifikate nach einem Stichtag, eine bestimmte Nutzung oder einen Root in einem Programm, während eine private Ausnahme erhalten bleibt. Jede Maßnahme verlangt ein anderes erwartetes Testergebnis.

Der Nenner sind deshalb nicht registrierte Geräte, sondern Kohorten von Validierungssystemen: Browser und Version, Betriebssystem-Store, Laufzeit, vertrauensrelevantes Laufzeitpaket, Basis-Image, Firmware, eingebetteter Client und verwaltete Ausnahme. Für jede Kohorte sind Root-Fingerabdruck, beobachtete Kette und erwartete Annahme oder Ablehnung zu sichern. Ein veralteter Client, der nach einem Sicherheits-Distrust weiter verbindet, ist ein Fehler, auch wenn der Verfügbarkeitsmonitor grün bleibt.

Öffentliche Programmdokumente belegen Regeln und Verteilung, nicht Inventar, Ausnahmen, Firmware-Zyklen oder tatsächliche Ergebnisse eines Betreibers. Die operative Schlussfolgerung ist eine Ableitung: Die Vertrauensänderung muss mit den Systemen abgeglichen werden, die tatsächlich Zertifikate validieren. Sie behauptet keinen Ausfall eines Kunden, Root-Betreibers oder einer Plattform.

Quellen