Zertifikatskette und Vertrauenskette (Chain of Trust)

Damit Computer, Browser oder Firewalls einem Zertifikat vertrauen,
müssen sie nachvollziehen können, wer es ausgestellt hat und
ob die ausstellende Stelle selbst vertrauenswürdig ist.
Dafür existiert das Prinzip der Zertifikatskette, auch „Chain of Trust“ genannt.

Man kann sich diese Kette wie eine Reihe von Unterschriften vorstellen:
Jede Instanz bestätigt die Echtheit der nächsten.

Was ist eine Zertifikatskette?

Eine Zertifikatskette beschreibt die Hierarchie von Zertifizierungsstellen (CAs),
die vom obersten Vertrauensanker („Root CA“) bis zum eigentlichen Serverzertifikat reicht.

Root CA
   ↓ signiert
Intermediate CA
   ↓ signiert
Endzertifikat (Server oder Client)

Jedes Glied in dieser Kette wird durch das darüberliegende bestätigt.
Das bedeutet: Wenn dem Root-Zertifikat vertraut wird,
wird auch automatisch allen darunterliegenden Instanzen vertraut.

Die drei Ebenen im Überblick

Ebene	Bezeichnung	Beschreibung
Root-Zertifikat	Vertrauensanker	Selbstsigniertes Zertifikat, das in Browsern oder Betriebssystemen vorinstalliert ist.
Intermediate-Zertifikat(e)	Zwischenstellen	Von der Root signiert. Sie stellen operative Zertifikate für Endnutzer oder Server aus.
Endzertifikat (Leaf Certificate)	Endnutzer/Server	Wird vom Intermediate signiert und auf Servern, Websites oder Endgeräten eingesetzt.

Root-Zertifikate

Root-Zertifikate sind die höchste Instanz der Public Key Infrastructure (PKI).
Sie signieren keine Endzertifikate direkt, sondern nur Zwischenzertifikate.
Damit bleibt der hochsensible Root-Key weitgehend offline und geschützt –
meist in Hardware-Security-Modulen (HSMs).

Beispiel:

CN = ISRG Root X1
O  = Internet Security Research Group
C  = US

Da sie selbstsigniert sind, kann man ihre Echtheit nicht prüfen.
Daher liegt die Vertrauensentscheidung beim Nutzer oder Betriebssystem:
Root-Zertifikate werden manuell oder durch Updates in den sogenannten Trust Store aufgenommen.

Intermediate-Zertifikate

Zwischenzertifikate stellen die Verbindung zwischen Root und Endzertifikaten her.
Sie übernehmen die praktische Ausstellung von Zertifikaten
und können bei Bedarf erneuert oder widerrufen werden, ohne das Root anzutasten.

Beispiel:

CN = R3
O  = Let's Encrypt
C  = US
Issued by: ISRG Root X1

Ein Browser prüft, ob dieses Intermediate tatsächlich vom bekannten Root signiert wurde.
Nur wenn das der Fall ist, darf das Intermediate seinerseits neue Zertifikate ausstellen.

Endzertifikat (Server/Client)

Das Endzertifikat ist das, was du z. B. auf deiner Website oder deinem VPN-Gateway nutzt.
Es enthält den Domainnamen, den öffentlichen Schlüssel und den Verwendungszweck.

CN = informatik-pruefung.de
O  = Studio Reichert
C  = DE
Issued by: R3

Dieses Zertifikat beweist die Identität des Servers gegenüber dem Client
und ist das letzte Glied der Kette – es darf keine weiteren Zertifikate ausstellen.

Wie der Browser die Kette überprüft

Beim Aufbau einer HTTPS-Verbindung läuft die Vertrauensprüfung in mehreren Schritten:

Server sendet Zertifikate:
Der Webserver übermittelt sein eigenes Zertifikat und meist auch die Intermediates.
Browser sucht Root-Zertifikat:
Der Browser schaut in seinem lokalen Trust Store nach,
ob die Root-CA bekannt ist, die am Ende der Kette steht.
Signaturen prüfen:
Jede Signatur wird einzeln verifiziert –
das Serverzertifikat muss vom Intermediate stammen,
das Intermediate wiederum von der Root.
Gültigkeit & Sperrstatus prüfen:
Der Browser vergleicht Ablaufdaten und prüft über CRL oder OCSP,
ob eines der Zertifikate widerrufen wurde.

Wenn alle Prüfungen erfolgreich sind, gilt die Verbindung als vertrauenswürdig.
Andernfalls erscheint ein Sicherheitswarnung wie:

Fehlende Zwischenzertifikate

Ein häufiger Fehler ist eine unvollständige Zertifikatskette.
Wenn der Server das Intermediate-Zertifikat nicht mitsendet,
kann der Browser die Kette nicht vervollständigen und lehnt die Verbindung ab.

Lösung:
Das Intermediate-Zertifikat muss in der Serverkonfiguration ergänzt werden,
meist über eine Datei wie chain.pem oder fullchain.pem.

Zertifikatskette (Beispiel)

Klicke auf eine der Instanzen, um das zugehörige Zertifikat einzublenden.

Root CA – ISRG Root X1

Intermediate CA – Let's Encrypt R3

Server-Zertifikat – informatik-pruefung.de

Um eine vollständige Vertrauenskette bereitzustellen, werden alle Zertifikate –
beginnend mit dem Server-Zertifikat und endend mit der Root-CA –
in einer gemeinsamen Datei gespeichert.
Diese sogenannte Full Chain oder fullchain.pem wird auf dem Server hinterlegt
und vom Client beim Verbindungsaufbau geprüft.

Selbstsignierte Zertifikate

Ein selbstsigniertes Zertifikat ist gleichzeitig Aussteller und Empfänger.
Solche Zertifikate werden oft intern verwendet (z. B. in Test- oder Laborumgebungen),
sind aber nicht automatisch vertrauenswürdig.

Damit Clients sie akzeptieren, müssen sie manuell in den lokalen Trust Store importiert werden.

Warum diese Kette so wichtig ist

Die Zertifikatskette erlaubt es, Vertrauen zu vererben,
statt es für jedes Zertifikat einzeln zu definieren.

Statt Millionen von Serverzertifikaten zu speichern,
müssen Browser und Betriebssysteme nur einigen Dutzend Root-CAs vertrauen.
Von dort wird Vertrauen an die darunterliegenden Stufen weitergegeben –
sicher, überprüfbar und skalierbar.

Man kann sich das vorstellen wie eine digitale Unterschriftenhierarchie:
Ein Root bürgt für ein Intermediate,
das Intermediate bürgt für dich –
und der Browser prüft, ob diese Kette lückenlos und gültig ist.