DNS RobotDNS Propagation Checker
StartDNSWHOISIPSSL
DNS RobotDNS Propagation Checker

DNS-Propagation-Checker der nächsten Generation

DatenschutzrichtlinieNutzungsbedingungenÜber unsBlogKontakt

DNS-Tools

DNS-AbfrageDomain zu IPNS-AbfrageMX-AbfrageCNAME-AbfrageAlle anzeigen

E-Mail-Tools

SPF-Eintrag-CheckerDMARC-CheckerDKIM-CheckerSMTP-Test-ToolE-Mail-Header-AnalyseAlle anzeigen

Website-Tools

WHOIS-AbfrageDomain-VerfügbarkeitSubdomain-FinderCMS-ErkennungLink-AnalyseAlle anzeigen

Netzwerk-Tools

Ping-ToolTraceroutePort-CheckerHTTP-Header-CheckSSL-Zertifikat-CheckAlle anzeigen

IP-Tools

IP-AbfrageMeine IP-AdresseIP-Blacklist-CheckIP zu HostnameASN-AbfrageAlle anzeigen

Hilfs-Tools

QR-Code-ScannerQR-Code-GeneratorMorsecode-ÜbersetzerText-zu-Binär-KonverterKleintext-GeneratorAlle anzeigen
© 2026 DNS Robot. Entwickelt von: ❤ Shaik Brothers
Alle Systeme betriebsbereit
Made with
Home/Blog/Was ist eine SSL-Zertifikatskette? So funktioniert sie

Was ist eine SSL-Zertifikatskette? So funktioniert sie

Shaik VahidFeb 26, 20268 min read
SSL-Zertifikatskette-Diagramm mit Stamm-, Zwischen- und Serverzertifikaten in einer Vertrauenskette
SSL-Zertifikatskette-Diagramm mit Stamm-, Zwischen- und Serverzertifikaten in einer Vertrauenskette

Key Takeaway

Eine SSL-Zertifikatskette ist die geordnete Abfolge digitaler Zertifikate, die das SSL-Zertifikat Ihres Servers mit einer vertrauenswürdigen Stammzertifizierungsstelle verbindet. Sie besteht typischerweise aus drei Ebenen: Stammzertifikat (in Browsern vorinstalliert), Zwischenzertifikat (Brücke) und Serverzertifikat (auf Ihrem Server). Jedes Glied muss gültig sein, damit der Browser der Verbindung vertraut.

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, sehen Sie das Schloss-Symbol. Wenn ein Glied fehlt, abgelaufen oder ungültig ist, erhalten Sie stattdessen eine Sicherheitswarnung.

Die drei Glieder jeder Zertifikatskette

Die meisten SSL-Zertifikatsketten haben genau drei Ebenen. Das Verständnis jeder einzelnen ist für die Fehlerbehebung von HTTPS-Problemen unerlässlich.

StammzertifikatZwischenzertifikatServerzertifikat (Leaf)
Signiert vonSich selbst (selbstsigniert)Stamm-CAZwischen-CA
SpeicherortBrowser/OS-VertrauensspeicherVon Ihrem Server gesendetVon Ihrem Server gesendet
Typische Lebensdauer20–25 Jahre5–10 Jahre90 Tage – 1 Jahr
Bei KompromittierungAlle Zertifikate ungültig — katastrophalNur Zwischenzertifikat widerrufenWiderrufen und neu ausstellen
Ungefähre Anzahl~150 vertrauenswürdige Stamm-CAs weltweitTausendeHunderte Millionen

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.

Es gibt etwa 150 Stamm-CAs, denen große Browser standardmäßig vertrauen. Organisationen wie DigiCert, Let's Encrypt (ISRG), Sectigo und GlobalSign betreiben Stammzertifikate. Da Stammschlüssel so kritisch sind, speichern CAs sie in Hardware-Sicherheitsmodulen (HSMs) in physisch gesicherten, vom Netzwerk getrennten Tresoren.

Zwischenzertifikat

Zwischenzertifikate befinden sich zwischen dem Stammzertifikat und Ihrem Serverzertifikat. Die Stamm-CA signiert das Zwischenzertifikat, und die Zwischen-CA signiert dann die Endentitätszertifikate (Serverzertifikate). Die meisten CAs verwenden ein oder zwei Zwischenzertifikate.

Ihr Webserver muss während des TLS-Handshakes die Zwischenzertifikate zusammen mit dem Serverzertifikat senden. Anders als Stammzertifikate sind Zwischenzertifikate nicht in Browsern vorinstalliert — wenn Ihr Server sie nicht sendet, bricht die Kette.

Warning

Der häufigste SSL-Kettenfehler ist ein fehlendes Zwischenzertifikat. Wenn Ihr Server nur das Serverzertifikat sendet, können Browser die Kette nicht aufbauen und zeigen eine Sicherheitswarnung an.

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:

  • Server sendet Zertifikate — Ihr Webserver sendet sein Serverzertifikat plus alle Zwischenzertifikate an den Browser.

  • Browser baut die Kette auf — Der Browser ordnet die Zertifikate in der Reihenfolge: Server → Zwischen → Stamm. Er identifiziert das Stammzertifikat durch Abgleich mit seinem Vertrauensspeicher.

  • Signaturprüfung — Beginnend beim Serverzertifikat überprüft der Browser, ob die digitale Signatur jedes Zertifikats vom privaten Schlüssel des nächsten Zertifikats in der Kette erstellt wurde.

  • Stammabgleich — Der Browser bestätigt, dass das Stammzertifikat an der Spitze der Kette in seinem eingebauten Vertrauensspeicher vorhanden ist. Wenn das Stammzertifikat nicht erkannt wird, schlägt die Verifizierung fehl.

  • Gültigkeitsprüfungen — Für jedes Zertifikat in der Kette prüft der Browser: nicht abgelaufen, nicht widerrufen (via CRL oder OCSP) und die Domain des Serverzertifikats stimmt mit der URL überein.

Was nach der Verifizierung passiert

Wenn alle Prüfungen bestanden werden, stellt der Browser eine verschlüsselte Verbindung her und zeigt das Schloss-Symbol an. Wenn eine einzelne Prüfung fehlschlägt — selbst bei einem Zwischenzertifikat — zeigt der Browser eine Warnung wie "Ihre Verbindung ist nicht privat" oder "NET::ERR_CERT_AUTHORITY_INVALID."

Deshalb ist die gesamte Kette wichtig, nicht nur das Serverzertifikat. Ein abgelaufenes Zwischenzertifikat wird HTTPS genauso gründlich unterbrechen wie ein abgelaufenes Serverzertifikat.

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:

bash
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep -E 's:|i:'

Tip

Suchen Sie nach "Verify return code: 0 (ok)" in der vollständigen Ausgabe. Jeder andere Code bedeutet, dass die Kette ein Problem hat. Code 21 bedeutet, dass die Kette unvollständig ist (fehlendes Zwischenzertifikat).

Methode 2: Browser-Zertifikatanzeige

Jeder große Browser ermöglicht die Inspektion der Zertifikatskette ohne spezielle Tools:

  • Klicken Sie auf das Schloss-Symbol in der Adressleiste

  • Wählen Sie "Verbindung ist sicher" → "Zertifikat ist gültig"

  • Öffnen Sie den Reiter "Zertifizierungspfad" (Chrome/Edge) oder "Details" (Firefox)

  • Sie sehen die vollständige Kette vom Stamm (oben) zum Server (unten)

Methode 3: DNS Robot SSL-Checker

Der schnellste Weg, die Zertifikatskette einer Website zu prüfen, ist ein Online-Tool. Unser SSL-Checker zeigt die vollständige Kette, Ausstellerdetails, Gültigkeitsdaten und den Verifizierungsstatus — alles mit einem Klick. Geben Sie eine beliebige Domain ein und sehen Sie die vollständige Kette sofort.

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 verify the first certificate" oder "incomplete certificate chain"

Ursache: Ihr Server sendet nur das Serverzertifikat ohne das Zwischenzertifikat. Desktop-Browser umgehen dies manchmal, indem sie Zwischenzertifikate aus früheren Besuchen zwischenspeichern, aber mobile Browser und API-Clients scheitern fast immer.

Lösung: Laden Sie das Zwischenzertifikat aus der Dokumentation Ihrer CA herunter und fügen Sie es zur Zertifikatsdatei Ihres Servers hinzu. In Nginx verketten Sie sie zu einer Datei:

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

Selbstsigniertes Zertifikat in der Kette

Fehlermeldung: "self-signed certificate in certificate chain"

Ursache: Entweder wurde das Stammzertifikat unnötigerweise in die vom Server gesendete Kette aufgenommen, oder ein Zertifikat ist tatsächlich selbstsigniert und nicht von einer vertrauenswürdigen CA.

Lösung: Entfernen Sie das Stammzertifikat aus der Kettendatei Ihres Servers. Ihr Server sollte nur das Server- + Zwischenzertifikat(e) senden. Browser haben das Stammzertifikat bereits — es zu senden ist unnötig und kann diesen Fehler verursachen.

Falsche Zertifikatsreihenfolge

Fehlermeldung: Die Kettenverifizierung kann stillschweigend fehlschlagen oder Warnungen "Zertifikat nicht vertrauenswürdig" erzeugen.

Ursache: Die Zertifikate in der Kettendatei sind in der falschen Reihenfolge.

Lösung: Die richtige Reihenfolge ist immer: Serverzertifikat zuerst, dann Zwischenzertifikat(e) vom nächsten zum Server bis zum nächsten zum Stamm. Niemals das Stammzertifikat einschließen.

Note

Die korrekte Kettenreihenfolge für Ihren Server ist: (1) Serverzertifikat, (2) Zwischenzertifikat(e), geordnet vom Signierenden Ihres Serverzertifikats bis zum vom Stamm signierten. Schließen Sie das Stammzertifikat nicht ein.

Abgelaufenes Zertifikat in der Kette

Fehlermeldung: "certificate has expired" — aber das Ablaufdatum Ihres Serverzertifikats sieht korrekt aus.

Ursache: Ein Zwischenzertifikat in der Kette ist abgelaufen. Dies ist seltener, kann aber vorkommen, wenn CAs ihre Zwischenzertifikate rotieren.

Lösung: Laden Sie das aktuelle Zwischenzertifikat von Ihrer CA herunter und ersetzen Sie das alte. Verwenden Sie dann unseren SSL-Checker, um die aktualisierte Kette zu überprüfen.

Best Practices für Zertifikatsketten

  • Installieren Sie immer Zwischenzertifikate — Gehen Sie nie davon aus, dass der Browser es von allein herausfindet. Konfigurieren Sie Ihren Server immer so, dass er die vollständige Kette sendet (Server + Zwischenzertifikate).

  • Senden Sie nicht das Stammzertifikat — Browser haben bereits Stammzertifikate. Das Einschließen des Stamms verschwendet Bandbreite und kann bei einigen Clients Fehler auslösen.

  • Halten Sie die richtige Reihenfolge ein — Serverzertifikat zuerst, Zwischenzertifikate danach, kein Stamm. Einige Server sind bei der Reihenfolge streng; andere tolerieren es, sind aber möglicherweise langsamer bei der Verifizierung.

  • Überwachen Sie den Ablauf — Auch Zwischenzertifikate laufen ab. Richten Sie Warnungen ein oder verwenden Sie automatisches Zertifikatsmanagement (wie certbot mit Let's Encrypt).

  • Prüfen Sie nach Änderungen — Nach der Erneuerung eines Zertifikats oder einem Hosting-Wechsel prüfen Sie immer die Kette mit einem Tool wie unserem SSL-Checker. Was vor der Erneuerung funktionierte, funktioniert möglicherweise nicht danach, wenn die CA ihr Zwischenzertifikat geändert hat.

  • Verwenden Sie OCSP Stapling — Aktivieren Sie OCSP Stapling auf Ihrem Server, damit Browser den Widerrufsstatus von Zertifikaten schneller überprüfen können, ohne die CA direkt zu kontaktieren.

Prüfen Sie jetzt Ihre SSL-Zertifikatskette

Verwenden Sie den kostenlosen SSL-Checker von DNS Robot, um Ihre Zertifikatskette zu überprüfen, Ablaufdaten zu kontrollieren und Ausstellerdetails einzusehen — alles mit einem Klick.

Try SSL-Checker

Frequently Asked Questions

Eine SSL-Zertifikatskette ist die geordnete Abfolge digitaler Zertifikate, die das SSL-Zertifikat Ihrer Website mit einer vertrauenswürdigen Stammzertifizierungsstelle (CA) verbindet. Sie umfasst typischerweise drei Ebenen: das Serverzertifikat (Leaf), ein oder mehrere Zwischenzertifikate und das Stammzertifikat, dem Ihr Browser bereits vertraut.

Related Tools

Ssl CheckerDns LookupDomain Health

Table of Contents

  • Was ist eine SSL-Zertifikatskette?
  • Die drei Glieder jeder Zertifikatskette
  • Wie die Vertrauenskette funktioniert
  • Warum Zwischenzertifikate existieren
  • So prüfen Sie Ihre SSL-Zertifikatskette
  • Häufige Zertifikatskettenfehler und ihre Behebung
  • Best Practices für Zertifikatsketten
  • FAQ