Zertifikatskette

Ketten existieren, damit die wertvollsten Schlüssel offline bleiben können. Ein Root signiert eine Handvoll Zwischenzertifikate und wandert dann zurück in einen Safe, und die Zwischenzertifikate erledigen die tägliche Arbeit des Signierens von Servern. Die Verifikation läuft in die andere Richtung, vom Zertifikat, das Ihnen ausgehändigt wurde, hin zu etwas, das Ihr Gerät bereits hatte, und sie schlägt fehl, wenn ein Glied fehlt, abgelaufen oder nicht erkannt ist.

So funktioniert es

Drei Positionen bilden eine typische Kette, und ein Server überträgt nur zwei davon.

Unten steht das Endzertifikat, ausgestellt für eine bestimmte Gruppe von Domainnamen. Darüber liegen ein oder mehrere Zwischenzertifikate, deren Zweck es ist, den Root vom täglichen Gebrauch abzuschirmen. Oben steht der Root, selbst signiert und seit lange vor Ihrem Besuch der Website in Ihrem Trust Store. Der Server sendet das Endzertifikat und die Zwischenzertifikate, denn das Senden des Roots würde Bytes hinzufügen und nichts beweisen: ein Root zählt nur, wenn Sie ihn bereits hatten.

Die Validierung ist kein gerader Weg eine Liste hinauf. Ein Zertifikat kann von mehr als einem Aussteller signiert sein, eine Praxis namens Cross-Signing, sodass ein Client mehrere mögliche Pfade vorfinden kann und einen finden muss, der in einem Root endet, den er besitzt. Deshalb lädt dieselbe Website auf einem neuen Laptop und schlägt auf einem alten Smartphone fehl. Die Pfade unterscheiden sich, weil die Trust Stores sich unterscheiden.

Das klarste Beispiel bleibt der Übergang von Let's Encrypt. Dessen eigener Root, ISRG Root X1, war vom älteren DST Root CA X3 kreuzsigniert, damit Geräte, die X1 noch nicht hinzugefügt hatten, trotzdem einen Pfad bilden konnten. DST Root CA X3 lief am 30. September 2021 ab. Geräte, die X1 besaßen, wechselten den Pfad, ohne dass es jemand bemerkte, während Android-Versionen älter als 7.1.1 und mehrere ältere TLS-Bibliotheken das nicht taten und Verbindungen weltweit an einem einzigen Nachmittag abbrachen. Nichts war gehackt worden und kein Schlüssel war durchgesickert. Ein Datum war verstrichen.

Wo Sie ihr begegnen

Probleme mit der Kette wirken alarmierend und sind fast immer banal.

Die häufigste Fehlkonfiguration eines Servers ist ein vergessenes Zwischenzertifikat. Browser übertünchen es oft, indem sie Zwischenzertifikate aus früheren Besuchen zwischenspeichern oder sie von einer URL im Zertifikat abrufen, sodass die Website für den Administrator funktioniert und für Kommandozeilenwerkzeuge und Smartphones fehlschlägt, was ihn zu einem unvergesslich lästigen Fehler bei der Fehlersuche macht.

Für alle, die Bitcoin verwalten, ist die nützliche Lesart eines Kettenfehlers eine diagnostische. Wenn eine Börse auf einem Gerät einen Zertifikatsfehler wirft und auf einem anderen funktioniert, liegt der Unterschied fast immer beim Gerät: eine falsch gestellte Systemuhr, ein Betriebssystem, das zu alt ist, um einen neueren Root erhalten zu haben, oder ein Antivirenprodukt, das sich in die Verbindung einschaltet. Beheben Sie das Gerät, bevor Sie einen Angriff vermuten, und klicken Sie niemals die Warnung weg, um hineinzugelangen.

Die Attestierung von Hardware-Wallets nutzt dieselbe Form in viel kleinerem Maßstab, mit einem Root des Herstellers, manchmal einem Zwischenzertifikat und einem Zertifikat auf dem Gerät selbst.

Zertifikatskette vs. Root-Zertifikat

Eine Kette ist ein Pfad; ein Root ist der Punkt, an dem der Pfad enden muss. Jedem Zertifikat in der Kette außer dem Root wird nur vertraut, weil etwas über ihm es signiert hat, während dem Root vertraut wird, weil er auf einer Liste steht, mit der Ihr Gerät ausgeliefert wurde, und er sich selbst signiert. Ein Root zu dieser Liste hinzuzufügen ist daher eine viel größere Entscheidung als jedes andere Zertifikat zu akzeptieren, und genau dazu fordern Sie Unternehmensnetzwerke und Werkzeuge zur Verkehrsüberwachung auf.