suche
ESC

Zertifikatsketten & Trust

Root, Intermediate und Leaf zur Vertrauenskette zusammensetzen und Lücken erkennen.

Second-Level Security 30 Min +150 XP

Worum geht’s

Ein einzelnes gültiges Zertifikat reicht nicht — der Browser muss eine lückenlose Vertrauenskette bis zu einer bekannten Root-CA bilden können. „Unvollständige Kette” ist einer der häufigsten TLS-Fehler, der oft nur in manchen Clients auftritt. Im Second-Level versteht man Root/Intermediate/Leaf und kann Ketten-Probleme gezielt diagnostizieren.

Konzept

Vertrauen in TLS ist hierarchisch:

  • Root-CA — selbstsigniert, liegt im Trust-Store von Betriebssystem/Browser. Der Vertrauensanker. Roots werden selten direkt zum Signieren benutzt.
  • Intermediate-CA — von der Root signiert, signiert ihrerseits Server-Zertifikate. Sie schirmt die wertvolle Root ab.
  • Leaf / End-Entity — das eigentliche Server-Zertifikat, vom Intermediate signiert.

Die Chain-Building-Regel: Jedes Zertifikat wird durch das nächsthöhere signiert. Der Browser folgt der Kette Leaf → Intermediate → Root, bis er ein Zertifikat erreicht, das in seinem Trust-Store liegt. Formal: der Issuer eines Zertifikats muss dem Subject des darüberliegenden entsprechen.

Typischer Fehler — unvollständige Kette: Der Server sendet nur das Leaf, aber nicht das Intermediate. Clients, die das Intermediate zufällig gecacht haben, funktionieren; frische Clients brechen ab. Regel: Der Server muss Leaf und alle Intermediates ausliefern — die Root liefert er nicht (die hat der Client bereits).

Verwandt: Key↔Cert-Match. Das ausgelieferte Zertifikat muss zum privaten Schlüssel auf dem Server passen — der öffentliche Schlüssel im Zertifikat und der private Schlüssel sind ein Paar. Stimmen sie nicht überein, schlägt TLS schon beim Laden fehl.

Bringe die Zertifikate in Vertrauensreihenfolge: oben die präsentierte (Leaf), unten der Vertrauensanker (Root).

    Bringe die drei Karten in Vertrauensreihenfolge: Leaf oben (präsentiert), Root unten (Anker). Jede Karte wird von der darunterliegenden signiert.

    Beispiel-Fall

    Aufgabe: Eine API funktioniert im Browser, aber curl meldet „unable to get local issuer certificate”. Was ist los?

    1. Der Browser hatte das Intermediate aus früheren Verbindungen gecacht und konnte die Kette schließen — curl cacht nichts und scheitert.
    2. Chain-Check ausführen → die gelieferte Kette ansehen: Sie enthält nur das Leaf, das Intermediate fehlt.
    3. Der Issuer des Leaf zeigt auf eine Intermediate-CA, die der Server nicht mitschickt — die Kette bricht ab, bevor sie eine Root im Trust-Store erreicht.
    4. Lösung: Auf dem Server das Fullchain-PEM einbinden (Leaf + Intermediate(s)). Danach schließt sich die Kette für alle Clients — die Root bleibt beim Client.

    Anwenden

    ▶ Am Tool ausprobieren

    Wenn du prüfen willst, ob Zertifikat und privater Schlüssel zusammenpassen, nutzt du den Key-Cert-Matcher — er vergleicht die öffentlichen Schlüssel beider Seiten.

    1. Füge die Zertifikatskette (Leaf + Intermediate) als PEM ein.
    2. Prüfe, ob jedes Zertifikat vom nächsthöheren signiert ist (Issuer == Subject darüber).
    3. Erkenne, ob ein Intermediate fehlt oder die Reihenfolge falsch ist.
    Tool öffnen: /chain-checker ↗

    Selbsttest

    Praxis-Challenge

    ⚑ Praxis-Challenge

    Exportiere die komplette Zertifikatskette einer HTTPS-Seite (Browser → alle Zertifikate als PEM). Lade sie in den Chain-Checker und prüfe für jedes Glied, ob Issuer und Subject des nächsthöheren übereinstimmen. Stelle fest, ob die Kette bis zu einer Root vollständig ist — und nenne, welches Glied der Server selbst ausliefern muss und welches nicht.

    Tool öffnen: /chain-checker ↗

    Modul im Speedrun testen →