Zusammenfassung

  • DigiCert übernahm ein Geschäft und schuf einen Migrationspfad zu neuer Ausstellungsinfrastruktur. Google, Mozilla und Apple entschieden dennoch in ihren eigenen Clients, welche Altketten sie bis wann akzeptierten; Zeitpläne und Ausnahmen blieben verschieden.
  • Öffentliches PKI-Vertrauen ist eine widerrufliche Beziehung auf der Seite des Vertrauenden. Gültigkeitsdauer, korrekte Signatur und vollzogener Unternehmenskauf zwingen den nächsten Client nicht, eine Kette anzunehmen.

Was der Kaufvertrag nicht liefern konnte

Ein Unternehmenskauf kann Personal, Verträge, Systeme und Einnahmen übertragen. Im Fall Symantec eröffnete er zudem den Weg zu einer unabhängig betriebenen DigiCert-Infrastruktur. Die operative Wirkung einer öffentlichen Wurzel entsteht jedoch erst, wenn fremde Software sie als Vertrauensanker ausführt. Diese künftige Entscheidung gehörte nicht dem Verkäufer.

Mozilla zog deshalb eine scharfe Grenze: Vertrauen eines Root-Programms geht nicht automatisch zwischen Organisationen über. Die Übernahme änderte nichts am geplanten Auslaufen der alten Symantec-Wurzeln. Andernfalls könnte eine sanktionierte Zertifizierungsstelle durch Verkauf oder Umstrukturierung entkommen und unter anderem Namen im Wesentlichen unverändert weiterarbeiten.

Googles Darstellung benennt den Anlass. Ein öffentlicher Hinweis vom Januar 2017 führte zur Untersuchung fragwürdiger Website-Zertifikate. Organisationen hatten Ausstellungsfähigkeit ohne notwendige Aufsicht erhalten; der Vorgang gehörte zu einem wiederkehrenden Muster. Das Chrome-Team verlor das Vertrauen in die alte Infrastruktur.

Das war kein Urteil, jedes Symantec-Zertifikat sei betrügerisch. Es war eine Entscheidung über die allgemeine Vermutung zugunsten einer Hierarchie. Deshalb reichte die Sperre eines einzelnen Endzertifikats nicht. Neue und alte Ausstellung mussten getrennt, Bestände ersetzt und Clientregeln stufenweise geändert werden.

Vier Uhren für dieselbe Kette

Die erste Uhr war das Ausstellungsdatum. Chrome verwendete den 1. Juni 2016 als Grenze für die erste Phase in Chrome 66. Der 1. Dezember 2017 markierte den Übergang zur von DigiCert verwalteten Infrastruktur; spätere Ausstellungen aus dem Altsystem sollten Chrome nicht mehr erreichen. Chrome 70 entzog der Legacy-PKI breiter das Vertrauen, abgesehen von engen Ausnahmen.

Die zweite Uhr war der Software-Release. Eine Richtlinie verändert nicht am Veröffentlichungstag alle Geräte. Das Verhalten wanderte durch Canary, Beta und Stable. Google erlaubte Unternehmen vorübergehend, den Vertrauensentzug per Policy auszusetzen, beendete diese Möglichkeit jedoch am 1. Januar 2019. Sie kaufte lokal Zeit, stellte aber kein öffentliches Vertrauen wieder her.

Mozilla folgte einem eigenen Takt. Firefox 58 warnte in der Konsole, Firefox 60 wies betroffene vor dem 1. Juni 2016 ausgestellte Zertifikate zurück, und eine spätere Stufe sollte die alten Wurzeln mit wenigen Ausnahmen vollständig entfernen. Weil zahlreiche Websites noch nicht migriert waren, verschob Mozilla den letzten Schritt von Firefox 63 auf 64. Es wog verlängertes Sicherheitsrisiko gegen großflächige Erreichbarkeitsverluste ab.

Die dritte Uhr gehörte dem Website-Betreiber. Ein formal noch monatelang gültiges Zertifikat konnte vorher ausfallen. Mozilla schätzte Anfang März 2018, ungefähr ein Prozent der meistbesuchten Million Websites sei von Firefox 60 betroffen; unmittelbar vor der Veröffentlichung waren es weniger als 0,15 Prozent. Für die nächste Phase ergab eine andere Messung noch 3,5 Prozent. Das sind zeitgebundene Telemetrieausschnitte, keine globale Webstatistik. Sie zeigen dennoch, wie Vertrauenspolitik Inventar-, Austausch- und Testarbeit erzeugt.

Die vierte Uhr lag im installierten Clientbestand. Apple begann am 1. August 2018 mit teilweisem Vertrauensentzug. Für ein begrenztes Ausstellungsfenster blieb Akzeptanz bei Eintrag in einem anerkannten CT-Log möglich. Als Datum des vollständigen Entzugs für die gelisteten Symantec-CAs nennt Apple den 25. Februar 2020. Chrome, Firefox und Apple-Plattformen besaßen keinen gemeinsamen Weltschalter.

Daher konnte dasselbe Zertifikat für einen Nutzer funktionieren und beim nächsten scheitern. Nicht seine Bytes hatten sich geändert, sondern der lokal ausgeführte Vertrauenszustand.

Sichtbarkeit ist keine Legitimation

RFC 6962 beschreibt Certificate Transparency als nur wachsende Protokolle mit signierten Zeitstempeln und Konsistenzbeweisen. Domaininhaber können unerwartete Ausstellung finden; Prüfer können widersprüchliche Loghistorien nachweisen.

Der RFC nennt zugleich die Grenze: Ein signierter Zeitstempel garantiert nicht, dass das Zertifikat korrekt ausgestellt wurde. CT macht eine Behauptung sichtbar und zurechenbar. Es beweist weder das Recht des Antragstellers noch die Güte der Validierung oder eine Pflicht des Browsers, dem Aussteller zu vertrauen.

Apples Übergangsregel nutzte CT als eine Annahmebedingung in einem begrenzten Zeitraum, nicht als dauerhafte Absolution. Ein unerwarteter Logeintrag ist für ein Unternehmen der Beginn einer Untersuchung zu Antragsteller, Validierung, Auslieferung, Clientpopulation und Widerruf.

Wirksame Autorität entstand am Rand

Eine Root-CA wirkt zentral, erhält Macht aber erst durch Clients, die ihre Wurzel als Anker ausführen. Google konnte Chrome ändern, Mozilla Firefox, Apple seine Plattformen. Unternehmen konnten vorübergehend lokale Ausnahmen behalten, Websites eine andere Kette ausliefern. Jeder Akteur hatte starke, aber begrenzte Entscheidungsmacht.

Heng Lus Running-Code-Perspektive dient hier als offengelegter Analyserahmen, nicht als Tatsachenquelle. Institutionelle Ansprüche werden praktisch, wenn Teilnehmer entsprechende Regeln ausführen; technische Abhängigkeit allein erzeugt keine unbegrenzte Souveränität. Der Verkauf änderte keine Client-Truststores. Betreiber und Websites mussten eine Kette bereitstellen, deren Anerkennung die Vertrauenden weiterhin wählten.

Browsermacht bleibt deshalb nicht neutral. Wenige Anbieter konnten weltweite Umstellungskosten auslösen. Veröffentlichte Kriterien, Beweise, gestufte Umsetzung, befristete Ausnahmen und fallübergreifende Konsistenz sind nötig. Technische Durchsetzbarkeit beweist Wirksamkeit, nicht Gerechtigkeit.

Das belastbare Kontinuitätsinventar

Eine reine Ablaufdatenliste versagt. Erforderlich sind vollständige Ketten, mögliche Wurzelfamilien, Root-Programme wichtiger Nutzergruppen, Releasekanäle, Ausstellungsgrenzen, CT-Anforderungen, Sub-CA-Ausnahmen und ein Nachweis der Ersatzkette im realen Client.

Schlüsselkompromittierung, Fehlausstellung, Auditmangel, Endzertifikatwiderruf, Root-Distrust und Browser-Rollout müssen getrennt bleiben. Sie können zusammenwirken, besitzen aber unterschiedliche Eigentümer und Wirkpfade.

Auch Akquisitionsprüfung muss Kundenverträge, aktuelle Ausstellung, alte und neue Wurzeln, Unterstellungsverhältnisse, Auditpflichten, CT-Teilnahme und Austauschkosten einzeln bewerten. Umsatz an einer Kette mit Enddatum ist nicht gleichwertig mit bereits migriertem Umsatz.

Evidenzgrenzen

Die Primärquellen belegen Zeitpläne und Nichtübertragbarkeit, nicht die Fehlerhaftigkeit jedes Altzertifikats. Mozillas Prozentwerte sind punktuelle Messungen. Apples Datum gilt nicht für Chrome oder Firefox. Ein Root-Programm besitzt wirksame Autorität über seine Clients, jedoch keine universelle Souveränität über das Web.

Quellen