Zertifikatskette einfach erklärt: Root, Zwischenzertifikat und Chain of Trust

Ein Zertifikat ist nur so vertrauenswürdig wie die Stelle, die es unterschrieben hat. Doch woher weiß Ihr Browser, dass er dieser Stelle trauen darf? Die Antwort ist eine Zertifikatskette, auch Chain of Trust oder Vertrauenskette genannt: Vom Zertifikat der Website führt eine Reihe von Signaturen bis zu einem Stammzertifikat, das bereits auf Ihrem Gerät gespeichert ist. Dieser Artikel erklärt Stamm-, Zwischen- und Endzertifikate, zeigt die echte Kette von techuni.de, beschreibt, wie der Browser jede Stufe prüft, und nennt typische Fehler.

Warum ein Zertifikat allein nicht reicht

Ein Zertifikat bestätigt, dass ein öffentlicher Schlüssel zu einem Namen gehört; den Aufbau erklärt X.509-Zertifikat einfach erklärt. Unterschrieben ist es von einer Zertifizierungsstelle (CA). Um diese Unterschrift zu prüfen, braucht der Browser den öffentlichen Schlüssel der CA, und der steckt wiederum in einem Zertifikat, das jemand unterschrieben hat. Irgendwo muss diese Reihe enden: bei einem Schlüssel, dem das Gerät von vornherein vertraut.

Stammzertifikat, Zwischenzertifikat, Endzertifikat

Eine typische Kette hat drei Ebenen:

Stammzertifikat (Root): Es ist selbstsigniert, also von der CA mit ihrem eigenen Schlüssel unterschrieben. Vertrauen entsteht nicht durch die Signatur, sondern dadurch, dass Betriebssystem oder Browser das Zertifikat in ihrem Root Store mitliefern. Der private Schlüssel liegt meist offline in einem Hardware-Sicherheitsmodul und wird nur selten benutzt.
Zwischenzertifikat (Intermediate): Die Root unterschreibt ein oder mehrere Zwischenzertifikate, mit denen die CA im Alltag Zertifikate ausstellt. Wird ein Zwischenschlüssel kompromittiert, kann die CA ihn sperren, ohne die Root austauschen zu müssen, was Jahre dauern würde.
Endzertifikat (Leaf): das Zertifikat der Website selbst, ausgestellt vom Zwischenzertifikat. Es ist als Nicht-CA markiert und darf keine weiteren Zertifikate unterschreiben.

Der Server schickt beim Verbindungsaufbau das Endzertifikat und die Zwischenzertifikate mit, nicht aber die Root: Die hat der Browser schon. Wie das im TLS-Handshake abläuft, steht in wie funktioniert HTTPS.

Drei Ebenen untereinander: Das Stammzertifikat im Root Store signiert das Zwischenzertifikat, das Zwischenzertifikat signiert das Endzertifikat der Website. — Stamm-, Zwischen- und Endzertifikat.

Die echte Kette von techuni.de

Im November 2026 lieferte der Server von techuni.de vier Zertifikate aus:

0: techuni.de, ausgestellt von YE1 (Let’s Encrypt), gültig bis 2. Januar 2027.
1: YE1, ausgestellt von Root YE, gültig bis 2. September 2028.
2: Root YE, hier als Variante, die von ISRG Root X2 unterschrieben ist (gültig bis 2. September 2032).
3: ISRG Root X2, als Variante, die von ISRG Root X1 unterschrieben ist (gültig bis 2. September 2032).

ISRG Root X1 (RSA, seit 2015) steckt in praktisch allen Root Stores, ISRG Root X2 (elliptische Kurve P-384, seit 2020) in den meisten neueren. Root YE gehört zur neuen Generation, die Let’s Encrypt 2025 erzeugt hat und die erst in die Root Stores aufgenommen werden muss. Bis dahin sorgen die Kreuzsignaturen dafür, dass jedes Gerät einen Weg zu einer bekannten Root findet: Ein neueres Gerät kann schon bei X2 aufhören, ein älteres geht bis X1.

Fünf Kästen von links nach rechts: techuni.de, ausgestellt von YE1, YE1 von Root YE, Root YE kreuzsigniert von ISRG Root X2, X2 kreuzsigniert von ISRG Root X1 im Root Store. — Die echte Zertifikatskette von techuni.de mit Kreuzsignaturen.

Wie der Browser die Kette prüft

Der Browser baut aus dem Endzertifikat, den mitgeschickten Zwischenzertifikaten und seinem Root Store einen Pfad und prüft jede Stufe:

Signatur: Jedes Zertifikat muss mit dem öffentlichen Schlüssel des nächsthöheren korrekt signiert sein; zum Prinzip siehe digitale Signatur.
Gültigkeit: Kein Zertifikat der Kette darf abgelaufen oder noch nicht gültig sein. Dafür braucht das Gerät eine richtige Uhrzeit.
CA-Berechtigung: Alle Zertifikate über dem Endzertifikat müssen als CA markiert sein (Basic Constraints CA:TRUE) und Zertifikate signieren dürfen. Eine Längenbegrenzung (pathLen) kann festlegen, wie viele Ebenen darunter erlaubt sind.
Name und Zweck: Der aufgerufene Domainname muss im Feld Subject Alternative Name des Endzertifikats stehen, und das Zertifikat muss für die Server-Authentifizierung gedacht sein.
Sperrstatus und Transparenz: Der Browser prüft, ob ein Zertifikat gesperrt wurde, und ob es in öffentlichen Certificate-Transparency-Protokollen steht.

Schlägt eine Prüfung fehl, erscheint die bekannte Warnseite, etwa mit dem Code NET::ERR_CERT_AUTHORITY_INVALID, wenn kein Weg zu einer vertrauenswürdigen Root gefunden wurde.

Fünf Prüfpunkte: Signatur, Gültigkeit, CA-Berechtigung, Name und Zweck sowie Sperrstatus und Certificate Transparency. — Die Prüfungen beim Aufbau einer HTTPS-Verbindung.

Typische Fehler mit der Kette

Zwischenzertifikat fehlt: Der Server schickt nur das Endzertifikat. Manche Browser gleichen das aus: Chrome kann das fehlende Zertifikat über die Adresse im Zertifikat (Authority Information Access) nachladen, Firefox bringt eine Liste bekannter Zwischenzertifikate mit. Programme wie curl, Python-Skripte oder Apps scheitern dagegen mit Meldungen wie „unable to get local issuer certificate“. Deshalb immer die vollständige Kette konfigurieren; bei certbot ist das die Datei fullchain.pem.
Falsche Reihenfolge oder fremde Zertifikate: Die Kette sollte vom Endzertifikat aufwärts sortiert sein und nur passende Zertifikate enthalten.
Root mitgeschickt: schadet meist nicht, kostet aber Bytes bei jedem Verbindungsaufbau.
Veralteter Root Store: Als am 30. September 2021 das alte Stammzertifikat DST Root CA X3 ablief, scheiterten ältere Geräte und Programme, deren Root Store nie aktualisiert worden war.

Die Kette eines Servers zeigt dieser Befehl an:

openssl s_client -connect www.techuni.de:443 -servername www.techuni.de -showcerts </dev/null

Kreuzsignaturen: eine Kette, mehrere Wege

Eine neue CA oder eine neue Root-Generation braucht Jahre, bis sie in allen Root Stores angekommen ist. Damit sie trotzdem sofort funktioniert, lässt sie sich von einer etablierten Root kreuzsignieren: Es gibt dann zwei Zertifikate mit demselben Namen und demselben Schlüssel, eines selbstsigniert und eines von der älteren Root unterschrieben. Let’s Encrypt startete 2015 genau so, mit einer Kreuzsignatur von IdenTrust. Weil derselbe Schlüssel in beiden steckt, kann der Browser den kürzesten Weg wählen, den er kennt. Dass ein Browser verschiedene Wege finden kann, ähnelt der Suche nach Pfaden in einem Graphen; siehe Dijkstra-Algorithmus.

Häufige Fragen

Warum unterschreibt die Root nicht direkt die Website-Zertifikate? Weil der Root-Schlüssel so wertvoll ist, dass er offline bleiben soll. Zwischenzertifikate lassen sich austauschen und sperren, ohne Milliarden Geräte zu aktualisieren.

Kann ich der Kette einer Website selbst etwas hinzufügen? Sie können eigene Stammzertifikate in Ihr Gerät importieren, etwa für ein Firmennetz. Das sollte man nur bei Quellen tun, denen man wirklich vertraut, denn diese Root könnte dann Zertifikate für jede Website ausstellen.

Wie lang darf eine Kette sein? Technisch gibt es keine feste Grenze, praktisch sind es zwei bis vier Zertifikate. Jede Ebene vergrößert den Handshake.

Was passiert, wenn eine Root abläuft? Zertifikate, deren einziger Weg zu dieser Root führt, gelten nicht mehr. CAs erzeugen deshalb Jahre vorher Nachfolger und verteilen sie über Updates.

Fazit

Die Vertrauenskette führt vom Zertifikat der Website über ein oder mehrere Zwischenzertifikate zu einem Stammzertifikat im Root Store des Geräts. Der Browser prüft auf jeder Stufe Signatur, Gültigkeit, CA-Berechtigung und Zweck. Für Betreiber heißt das vor allem: immer die vollständige Kette ausliefern. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.