Zusammenfassung

  • Ein SCT ist die signierte Zusage eines Logs, einen Eintrag innerhalb der Maximum Merge Delay aufzunehmen; es ersetzt weder die Zertifikatsprüfung noch die CT-Regel des Browsers.
  • Eine Freigabe braucht externe Ergebnisse aus der vorgesehenen Client-Population samt Version, wirksamer Log-Liste und aktivem CT-Status.

Das Ausgabesystem meldet drei SCTs, alle Signaturen sind gültig, und das neue Zertifikat liegt an den vorgesehenen Endpunkten. Trotzdem bricht eine Browser-Gruppe die TLS-Verbindung ab. Der scheinbare Widerspruch entsteht, weil die Ausstellung einen Beleg erzeugt, der Client aber eine weitergehende Entscheidung trifft.

RFC 9162 beschreibt das SCT als Versprechen eines Certificate-Transparency-Logs. Nach Annahme einer Einreichung muss der Eintrag innerhalb der Maximum Merge Delay in den nur erweiterbaren Merkle-Baum gelangen. Aufnahme und Konsistenz lassen sich anschließend prüfen. Die RFC stellt zugleich klar, dass ein gültiges SCT die normale Validierung des Serverzertifikats und seiner Kette nicht ersetzt.

Chrome bewertet zusätzlich den Übertragungsweg, die Zahl unterschiedlicher Logs, die Unabhängigkeit ihrer Betreiber sowie den Log-Zustand bei SCT-Ausstellung und Zertifikatsprüfung. Für eingebettete SCTs in Zertifikaten mit höchstens 180 Tagen Laufzeit verlangt die aktuelle Richtlinie mindestens zwei verschiedene Logs und zwei verschiedene Betreiber; bei der Prüfung muss mindestens ein Log weiterhin in einem anrechenbaren Zustand sein. Für über TLS gelieferte SCTs gilt eine andere Kombination.

Die Kennzahl „drei gültige SCTs“ kann deshalb täuschen. Sie zeigt weder Betreiber-Konzentration noch einen späteren Zustandswechsel oder einen unpassenden Lieferweg.

Die wirksame Log-Liste gehört zum Prüfergebnis

Chrome veröffentlicht täglich eine neue CT-Log-Liste. Sie ordnet Logs, Betreiber und Lebenszykluszustände zu. Die Entscheidung hängt damit nicht von einer ewigen Vertrauensliste ab, sondern vom Wissen des Clients zum Prüfzeitpunkt.

Hinzu kommt ein 70-Tage-Limit. Ist die frischeste vom Client gespeicherte unterstützte Liste zu alt, schaltet Chrome die CT-Durchsetzung ab. Ein erfolgreicher Test auf einem ungepflegten Gerät kann also fehlende Durchsetzung anzeigen statt aktuelle Konformität. Der Nachweis muss Browser-Version, Listenzeitstempel und Durchsetzungsstatus festhalten.

Chromes Liste ist auch keine allgemeine Norminstanz. Google grenzt ihre Nutzung auf Einreicher, Beobachter und Prüfer im Chrome-Ökosystem ein und warnt andere User Agents vor einer eigenen Durchsetzung auf dieser Basis. Apple veröffentlicht andere Kriterien: aktuell und früher genehmigte Logs werden unterschieden, SCT-Kombinationen eigenständig festgelegt und Beiträge desselben Betreibers begrenzt. Ein gemeinsames Protokoll ergibt keine universelle Client-Entscheidung.

Zeitliche Shards machen Eignung befristet

Neue Chrome-anerkannte Logs müssen zeitlich aufgeteilt sein. Jeder Shard akzeptiert Zertifikate, deren notAfter in seinem Intervall liegt. Betreiber sollen lückenlose Zeiträume bereitstellen; der Aussteller muss trotzdem Laufzeit, Log-Zustand und Betreiber gemeinsam betrachten.

Chromes Hinweis für Website-Betreiber macht die Folge deutlich: CT-Informationen eines bestehenden Zertifikats können vor dem Zertifikat selbst ihre Gültigkeit verlieren. Dann können neue SCTs über TLS oder ein Ersatzzertifikat nötig werden. Ein reiner Ablaufalarm erkennt diese frühere Akzeptanzfrist nicht.

Gesichert sind hier die RFC-Definition und die veröffentlichten Richtlinien von Chrome und Apple. Der vorgeschlagene Abgleich mit echten Clients ist eine betriebliche Schlussfolgerung. Öffentliche Quellen verraten weder Browser-Mix noch Ausnahmen, Endpunkte, Simulationsgüte oder Störungen eines konkreten Unternehmens. Sie belegen auch keinen aktuellen Fehler einer Zertifizierungsstelle, eines Logs oder Browsers. Diese Punkte bleiben ohne eigene Messung unbekannt.

Ein Akzeptanzregister sollte Fingerabdruck, Namen und Endpunkte, SCT-Lieferweg, Log-IDs und Zeitstempel, wirksame Chrome- und Apple-Regeln, getesteten Client und Version, externes Handshake-Ergebnis, Ausnahme, Verantwortlichen und Austauschreserve verbinden. Die Ausgabekette besitzt den Beleg; der Dienst schuldet den Nachweis, dass unterstützte Nutzer verbinden können.

Quellen