Zertifikatskette

Ein Zertifikat belegt nichts aus sich selbst heraus. Es gilt nur, weil eine Stelle es signiert hat, deren Zertifikat wiederum signiert ist — bis hinauf zu einem Wurzelzertifikat, das im Vertrauensspeicher des Clients liegt. Diese Folge ist die Zertifikatskette, auch Vertrauenskette genannt.

Wie die Kette aufgebaut ist

Jedes Zertifikat nennt zwei Namen: den eigenen Inhaber (Subject) und den Aussteller (Issuer). Der Aussteller des einen ist der Inhaber des nächsten:

Wurzelzertifikat        Subject: ISRG Root X1
  (selbstsigniert)      Issuer:  ISRG Root X1
        │
        ▼ signiert
Zwischenzertifikat      Subject: E6
                        Issuer:  ISRG Root X1
        │
        ▼ signiert
Serverzertifikat        Subject: netzikon.net
                        Issuer:  E6

Das Wurzelzertifikat ist selbstsigniert — es nennt sich selbst als Aussteller. Es gilt nicht, weil es mathematisch belegt wäre, sondern weil es im Vertrauensspeicher von Betriebssystem oder Browser hinterlegt ist. Diese Entscheidung ist der Ankerpunkt des ganzen Systems.

Warum es Zwischenzertifikate gibt

Technisch könnte eine Wurzel die Serverzertifikate direkt signieren. Dass sie es nicht tut, hat drei Gründe.

Der Wurzelschlüssel bleibt offline. Er liegt in einem Hardware-Sicherheitsmodul, oft in einem Tresor und ohne Netzverbindung. Benutzt wird er nur, um Zwischenzertifikate zu signieren — selten und unter Zeugen.

Ein Schaden bleibt begrenzt. Wird ein Zwischenzertifikat kompromittiert, lässt es sich sperren und ersetzen. Eine kompromittierte Wurzel wäre nicht zu retten.

Wurzeln sind träge. Ein neues Wurzelzertifikat muss in die Vertrauensspeicher von Windows, macOS, Android, iOS und allen Browsern gelangen — und dann müssen die Altgeräte aussterben, die kein Update mehr bekommen. Das dauert Jahre. Zwischenzertifikate lassen sich dagegen jederzeit wechseln.

Wie die Prüfung abläuft

Der Client arbeitet die Kette von unten nach oben ab und prüft bei jedem Glied:

Die Signatur. Stimmt sie mit dem öffentlichen Schlüssel des Ausstellers?

Den Gültigkeitszeitraum. Liegt der aktuelle Zeitpunkt zwischen notBefore und notAfter? Eine falsche Systemuhr ist eine erstaunlich häufige Fehlerursache.

Den Namen. Stimmt der angefragte Hostname mit einem Eintrag im Feld Subject Alternative Name (SAN) überein? Das frühere Common Name wird von modernen Clients nicht mehr ausgewertet.

Den Verwendungszweck. Erlauben Key Usage und Extended Key Usage die vorgesehene Verwendung?

Die Ausstellbefugnis. Setzt Basic Constraints das Flag CA:TRUE, und erlaubt pathLenConstraint die Tiefe der Kette? Ohne diese Prüfung könnte jeder Inhaber eines Serverzertifikats selbst Zertifikate ausstellen.

Den Sperrstatus. Über eine Sperrliste oder OCSP.

Bricht die Prüfung an einem Glied ab, ist die ganze Kette ungültig — auch wenn Server- und Wurzelzertifikat einwandfrei sind.

Der häufigste Fehler: die unvollständige Kette

Der Server muss sein eigenes Zertifikat und alle Zwischenzertifikate ausliefern. Die Wurzel braucht er nicht zu senden; sie liegt beim Client.

Fehlen die Zwischenzertifikate, entsteht ein Fehlerbild, das die Fehlersuche verschleppt: Im Browser funktioniert die Seite, mit curl, in einer App oder auf einem älteren Android-Gerät nicht. Der Grund ist, dass Browser fehlende Glieder nachladen oder aus früheren Verbindungen zwischengespeichert haben. Andere Clients tun das nicht — sie scheitern an derselben Konfiguration, die im Browser unauffällig bleibt.

Wer also eine Meldung über ein nicht vertrauenswürdiges Zertifikat nur auf manchen Geräten sieht, prüft zuerst die ausgelieferte Kette, nicht das Zertifikat:

openssl s_client -connect example.net:443 -showcerts

Reihenfolge und Dateiformate

In einer PEM-Datei gilt eine feste Reihenfolge: zuerst das Serverzertifikat, darunter die Zwischenzertifikate in aufsteigender Richtung. Eine falsche Reihenfolge lehnen manche Server ab, andere nehmen sie hin — ein weiterer Grund für schwer reproduzierbare Fehler.

Dass dieselbe Kette in verschiedenen Dateiformaten vorliegt, verwirrt zusätzlich:

Die Endung .cer taucht in beiden Welten auf und sagt nichts über die Kodierung. Wer unsicher ist, schaut in die Datei: Beginnt sie mit -----BEGIN, ist sie PEM.

Cross-Signing und der Wurzelwechsel

Eine neue Zertifizierungsstelle steht vor einem Henne-Ei-Problem: Ihre Wurzel ist in keinem Vertrauensspeicher, also gilt kein Zertifikat. Der Ausweg ist Cross-Signing — eine etablierte Wurzel signiert die neue zusätzlich. Das Zertifikat lässt sich dann über zwei Pfade prüfen, und ältere Clients finden den alten.

Praktisch vorgeführt wurde das beim Auslaufen des Wurzelzertifikats DST Root X3 im September 2021. Clients mit aktuellem Vertrauensspeicher wechselten unbemerkt auf die neuere Wurzel. Ältere Android-Geräte dagegen verloren das Vertrauen zu großen Teilen des Webs — ein Lehrstück darüber, dass die Kette nur so aktuell ist wie der Vertrauensspeicher am anderen Ende.