Was ist eine SSL-Zertifikatskette? So funktioniert sie

Was ist eine SSL-Zertifikatskette?

Eine SSL-Zertifikatskette (auch Vertrauenskette oder Zertifizierungspfad genannt) ist die geordnete Liste digitaler Zertifikate, die das SSL/TLS-Zertifikat Ihrer Website mit einer vertrauenswürdigen Stammzertifizierungsstelle (CA) verbindet. Jedes Zertifikat in der Kette wird vom darüber liegenden Zertifikat digital signiert und bildet so einen überprüfbaren Vertrauenspfad von Ihrem Server bis zu einer Stamm-CA, der die Browser bereits vertrauen.

Stellen Sie es sich wie eine Kette von Empfehlungen vor. Ihr Serverzertifikat sagt: „Ich bin example.com.“ Die Zwischen-CA sagt: „Ich bürge für das Zertifikat von example.com.“ Die Stamm-CA sagt: „Ich bürge für diese Zwischen-CA.“ Ihr Browser vertraut der Stamm-CA bereits, und durch das Verfolgen der Signaturkette vertraut er auch Ihrem Server.

Wenn Sie eine HTTPS-Website besuchen, verfolgt Ihr Browser diese Kette in Millisekunden. Wenn jedes Glied in Ordnung ist, wird die Seite ohne Warnung geladen. Fehlt ein Glied, ist es abgelaufen oder nicht vertrauenswürdig, erhalten Sie stattdessen eine Sicherheitswarnung wie NET::ERR_CERT_AUTHORITY_INVALID.

Die drei Arten von Zertifikaten in einer Kette

Jede Kette enthält drei Arten von Zertifikaten, wobei ein Server auch mehr als ein Zwischenzertifikat senden kann:

Stammzertifikat

Das Stammzertifikat ist der Vertrauensanker an der Spitze der Kette. Es ist selbstsigniert, was bedeutet, dass die Zertifizierungsstelle ihr eigenes Zertifikat signiert hat. Stammzertifikate sind in Ihrem Browser und Betriebssystem vorinstalliert — diese Sammlung wird als Vertrauensspeicher (Trust Store) bezeichnet.

Die eigene Root-Liste von Chrome enthält etwa 100 Roots (Chrome Root Store); Mozilla, Apple und Microsoft führen eigene Listen. Organisationen wie DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign und Google Trust Services betreiben Roots. Weil Root-Schlüssel so wertvoll sind, halten die CAs sie offline in Hardware-Sicherheitsmodulen und verwenden sie nur, um Zwischenzertifikate zu signieren.

Zwischenzertifikat

Zwischenzertifikate liegen zwischen dem Stammzertifikat und Ihrem Serverzertifikat. Die Stamm-CA signiert das Zwischenzertifikat, und die Zwischen-CA signiert dann die Endnutzer-Zertifikate (Serverzertifikate). Die meisten CAs verwenden ein oder zwei Zwischenzertifikate.

Ihr Webserver muss die Zwischenzertifikate während des TLS-Handshakes zusammen mit Ihrem Serverzertifikat senden. Chrome kann ein fehlendes Zwischenzertifikat herunterladen und Firefox liefert sie vorinstalliert mit, aber Apps, API-Clients und ältere Android-Geräte können beides nicht, sodass die Kette für sie bricht.

Serverzertifikat (Leaf-Zertifikat)

Das Serverzertifikat (auch Endentitäts- oder Leaf-Zertifikat genannt) ist das auf Ihrem Webserver installierte Zertifikat. Es enthält Ihren Domainnamen, Ihren öffentlichen Schlüssel, den Gültigkeitszeitraum und Informationen über den Aussteller (die Zwischen-CA, die es signiert hat).

Dies ist das erste Zertifikat, das Ihr Browser beim TLS-Handshake erhält. Der Browser arbeitet sich dann die Kette hinauf und überprüft jede Signatur, bis er ein vertrauenswürdiges Stammzertifikat erreicht.

Wie die Vertrauenskette funktioniert

Wenn sich Ihr Browser über HTTPS mit einer Website verbindet, löst der TLS-Handshake einen Kettenverifizierungsprozess aus, der in Millisekunden abläuft:

• Der Server sendet seine Zertifikate — das Leaf, dann die Zwischenzertifikate.
• Der Browser baut einen Pfad auf — vom Leaf bis zu einem Root in seiner eigenen Liste. Fehlt ein Zwischenzertifikat, lädt Chrome es von der im Zertifikat angegebenen Adresse (AIA) herunter, und Firefox nutzt seinen eigenen vorinstallierten Satz; viele andere Clients scheitern einfach.
• Signaturen werden geprüft — jedes Zertifikat muss mit dem Schlüssel des darüber liegenden Zertifikats signiert sein.
• Das Root wird geprüft — der Pfad muss bei einem Root in der Liste des Browsers enden. Ein unbekanntes Root schlägt fehl.
• Die Gültigkeit wird geprüft — jedes Zertifikat muss innerhalb seiner Gültigkeitsdaten liegen und darf nicht widerrufen sein, und das Leaf muss den Namen in der Adressleiste abdecken.

Echte Ketten: Was 12 große Websites senden

Wir haben am 27. Oktober 2026 bei 12 der größten Websites ihre Ketten abgefragt (openssl s_client -showcerts, von zwei Standorten). Keine sendete nur ein Leaf, und einige schickten zusätzliche kreuzsignierte Zertifikate, damit ältere Geräte noch ein Root erreichen, das sie kennen. Was ein Server sendet, kann sich mit Ihrer TLS-Version, der ECDSA-Unterstützung Ihres Clients und dem antwortenden CDN-Standort ändern: facebook.com etwa sendete über TLS 1.2 3 Zertifikate.

Was nach der Verifizierung passiert

Bestehen alle Prüfungen, kommt die Verbindung zustande. Schlägt eine einzige fehl, selbst bei einem Zwischenzertifikat, zeigt der Browser eine Warnung wie „Ihre Verbindung ist nicht privat“ mit einem Code wie NET::ERR_CERT_AUTHORITY_INVALID. (Fehler vor der Prüfung eines Zertifikats, im TLS-Handshake selbst, zeigen andere Codes: ERR_SSL_PROTOCOL_ERROR oder ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Deshalb kommt es auf die gesamte Kette an, nicht nur auf das Serverzertifikat. Ein abgelaufenes Zwischenzertifikat legt HTTPS genauso lahm wie ein abgelaufenes Serverzertifikat, es sei denn, der Client kann einen anderen Pfad darum herum aufbauen.

Warum Zwischenzertifikate existieren

Stamm-CAs könnten theoretisch jedes Serverzertifikat direkt signieren und Zwischenzertifikate ganz überspringen. Aber es gibt drei entscheidende Gründe, warum sie das nicht tun:

• Sicherheitsisolierung — Private Schlüssel der Stamm-CA werden offline in HSMs in physisch gesicherten Tresoren aufbewahrt. Sie werden nur zum Signieren von Zwischenzertifikaten verwendet, nicht für Millionen einzelner Serverzertifikate. Das reduziert das Risiko einer Kompromittierung des Stammschlüssels drastisch.
• Schadensbegrenzung — Wenn eine Zwischen-CA kompromittiert wird, sind nur die Zertifikate dieser Zwischen-CA betroffen. Die Stamm-CA kann die kompromittierte Zwischen-CA widerrufen und eine neue ausstellen — ohne jedes jemals ausgestellte Zertifikat ungültig zu machen.
• Betriebliche Flexibilität — CAs verwenden verschiedene Zwischenzertifikate für verschiedene Zwecke: eines für DV-Zertifikate, ein anderes für EV, separate für verschiedene Regionen oder Schlüsselalgorithmen (RSA vs. ECDSA).

So prüfen Sie Ihre SSL-Zertifikatskette

Es gibt drei Möglichkeiten, die Zertifikatskette einer Website zu überprüfen — von Befehlszeilentools bis hin zu browserbasierten Prüfungen.

Methode 1: OpenSSL (Befehlszeile)

Der openssl-Befehl ist die detaillierteste Methode zur Inspektion einer Zertifikatskette. Führen Sie dies in Ihrem Terminal aus:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Methode 2: Browser-Zertifikatanzeige

Jeder große Browser zeigt die Kette, die er aufgebaut hat (sie kann von der gesendeten abweichen, wenn er ein fehlendes Zwischenzertifikat selbst geholt hat):

• Chrome: Klicken Sie auf das Symbol links neben der Adresse → Verbindung ist sicher → Zertifikat ist gültig, öffnen Sie dann den Reiter Details, um die Zertifikatshierarchie zu sehen
• Edge: Klicken Sie auf das Schloss → „Connection is secure“ → das Zertifikatssymbol oben im Fenster
• Firefox: Klicken Sie auf das Schloss → „Connection secure“ → „More information“ → „View Certificate“; jedes Zertifikat der Kette hat einen eigenen Reiter
• Safari (ab 18.4): Wählen Sie in der Menüleiste Safari > Details zur Verbindungssicherheit (Apple); auf dem iPhone tippen Sie auf die linke Seite des Adressfelds → „Privacy & Security“ → „Connection Security Details“

Methode 3: DNS Robot SSL-Checker

Am schnellsten prüfen Sie von außerhalb Ihres Netzwerks mit unserem SSL-Checker: Er zeigt die vom Server gesendete Kette, ob die Root-Listen von Mozilla, Chrome, Apple und Microsoft ihr jeweils vertrauen, eine Warnung bei unvollständiger Kette und die Daten jedes Zertifikats. Bei Websites hinter Cloudflare liest er das Zertifikat aus öffentlichen CT-Logs, sodass dort die vom Server gesendete Kette nicht geprüft wird.

Häufige Zertifikatskettenfehler und ihre Behebung

Zertifikatskettenprobleme sind eine der häufigsten Ursachen für HTTPS-Fehler. Hier sind die Fehler, die Sie am wahrscheinlichsten antreffen, und wie Sie jeden beheben.

Fehlendes Zwischenzertifikat

Fehlermeldung: „unable to get local issuer certificate“ (curl, Python, PHP), „unable to verify the first certificate“ (Node.js) oder „incomplete certificate chain“

Ursache: Der Server sendet nur das Serverzertifikat. Chrome behebt das oft, indem es das Zwischenzertifikat selbst herunterlädt (der Prüfer von Apple ebenso), sodass die Website im Browser in Ordnung wirken kann, während curl unter Linux, Python, Java, Zahlungs-Callbacks und viele Apps scheitern.

Lösung: Senden Sie die Zwischenzertifikate zusammen mit dem Leaf. Bei Let's Encrypt zeigen Sie Ihren Server auf fullchain.pem, nicht auf cert.pem; bei einer anderen CA laden Sie deren Zwischenzertifikat herunter und legen es in einer Datei hinter Ihr Zertifikat:

cat your-domain.crt intermediate.crt > fullchain.crt

Selbstsigniertes Zertifikat in der Kette

Fehlermeldung: „self-signed certificate in certificate chain“ (OpenSSL-Fehler 19)

Ursache: Die Kette endet in einem Root, dem der Client nicht vertraut: einer privaten oder Firmen-CA oder einem Proxy bzw. Virenscanner, der den Datenverkehr mit einem eigenen Root neu signiert. Ein Root zu senden, dem der Client vertraut, ist harmlos, nur unnötig.

Lösung: Verwenden Sie für öffentliche Websites ein Zertifikat einer öffentlichen CA oder installieren Sie das private Root auf den Clients, die es brauchen. Das Root aus der Kette des Servers wegzulassen ist sauber, behebt diesen Fehler aber nicht.

Falsche Zertifikatsreihenfolge

Fehlermeldung: Die Kettenverifizierung schlägt in einigen Clients fehl, oder sie melden das Zertifikat als nicht vertrauenswürdig.

Ursache: Die Zertifikate in der Kettendatei sind in der falschen Reihenfolge. TLS 1.3 verlangt das eigene Zertifikat des Servers zuerst und die übrigen der Reihe nach, fordert Clients aber auf, mit anderen Reihenfolgen zurechtzukommen (RFC 8446 §4.4.2); ältere oder strengere Clients tun das womöglich nicht.

Lösung: Setzen Sie das Serverzertifikat an den Anfang, dann jedes Zwischenzertifikat, beginnend mit dem, das Ihr Leaf signiert hat.

Abgelaufenes Zertifikat in der Kette

Fehlermeldung: „certificate has expired“ — aber das Ablaufdatum Ihres Serverzertifikats sieht in Ordnung aus.

Ursache: Ein Zertifikat weiter oben in der Kette ist abgelaufen. Der bekannteste Fall: IdenTrusts DST Root CA X3, das das Root von Let's Encrypt kreuzsigniert hatte, lief am 30. September 2021 ab, und Geräte, die ISRG Root X1 nicht vertrauten (sowie Clients mit OpenSSL 1.0.x), scheiterten auf einmal auf Let's-Encrypt-Websites.

Lösung: Laden Sie das aktuelle Zwischenzertifikat von Ihrer CA herunter und ersetzen Sie das alte. Prüfen Sie die aktualisierte Kette anschließend mit unserem SSL-Checker.

Best Practices für Zertifikatsketten

• Senden Sie immer die Zwischenzertifikate — verlassen Sie sich nicht darauf, dass Browser die Kette reparieren; Apps und API-Clients tun es nicht.
• Das Root ist optional — Clients nutzen ihre eigene Kopie, ein Root, dem sie vertrauen, zu senden kostet nur Bytes; ein kreuzsigniertes Root für ältere Geräte ist eine bewusste Ausnahme.
• Behalten Sie die Reihenfolge bei — zuerst das Leaf, dann die Zwischenzertifikate von dem, das Ihr Leaf signiert hat, aufwärts.
• Automatisieren Sie die Erneuerung — Zertifikate, die seit März 2026 ausgestellt werden, gelten höchstens 200 Tage, ab März 2027 nur noch 100, und Let's Encrypt wechselt im Februar 2027 zu Zertifikaten mit 64 Tagen.
• Prüfen Sie nach jeder Erneuerung oder jedem Umzug — eine CA kann zwischen Erneuerungen das Zwischenzertifikat wechseln. Prüfen Sie die Website danach mit dem SSL-Checker.
• Behalten Sie jeden Namen im Blick — www, die Hauptdomain und jede Subdomain können mit unterschiedlichen Zertifikaten und Ketten ausgeliefert werden. Der Subdomain-Finder listet die Namen, die Ihre Zertifikate abgedeckt haben, aus öffentlichen Zertifikatsprotokollen.