Worum geht’s
„Im Browser geht’s, im Handy nicht” oder „curl meckert, der Browser nicht” — solche TLS-Rätsel liegen fast immer an einer unvollständigen Zertifikatskette. Wer Leaf, Intermediate(s) und Root korrekt zusammensetzt und die Signatur-Verkettung prüft, findet die Lücke systematisch. Dieser Skill macht aus dem Trust-Wissen ein belastbares Prüf-Vorgehen.
Konzept
Vertrauen in ein Server-Zertifikat entsteht über eine Kette:
- Leaf (End-Entity): das Server-Zertifikat für den Host.
- Intermediate(s): ein oder mehrere Zwischen-CA-Zertifikate.
- Root: die Wurzel-CA, die im Trust Store von Betriebssystem/Browser liegt.
Die Verkettung funktioniert über Issuer ↔ Subject: Der Issuer des Leaf entspricht dem
Subject des nächsten (Intermediate); dessen Issuer dem Subject der Root. Jedes Zertifikat
ist mit dem privaten Schlüssel des Ausstellers signiert — und genau diese Signatur prüft man
mit dem öffentlichen Schlüssel des Ausstellers (im nächsthöheren Zertifikat). Stimmt jede
Signatur und endet die Kette in einer vertrauenswürdigen Root, ist die Kette gültig.
Häufigste Fehler in der Praxis:
- Fehlendes Intermediate: Der Server liefert nur das Leaf. Browser cachen Intermediates oft und „verzeihen” das; strikte Clients (curl, Java, Mobile) nicht → „unable to get local issuer certificate”.
- Falsche Reihenfolge oder ein Intermediate aus einer anderen Hierarchie.
- Abgelaufenes Intermediate/Root.
- Die Root gehört nicht in das vom Server gelieferte Bundle — sie muss im Client-Trust-Store liegen. Mitgeschickt schadet sie nicht, ersetzt aber kein Vertrauen.
Eine gültige Kette führt vom Server-Zertifikat bis zur vertrauten Root:
Bringe die Zertifikate in Vertrauensreihenfolge: oben die präsentierte (Leaf), unten der Vertrauensanker (Root).
Beispiel-Fall
Aufgabe: curl https://api.firma.de meldet „unable to get local issuer certificate”, der
Browser zeigt die Seite normal.
- Leaf und gelieferte Zwischenzertifikate sammeln und in den Chain-Checker einfügen.
- Verkettung prüfen: Passt der Issuer des Leaf zum Subject eines vorhandenen Intermediates? Fehlt dieses Glied → genau die Lücke, die curl bemängelt.
- Signaturen prüfen: Verifiziert jede Stufe gegen den öffentlichen Schlüssel der nächsten?
- Befund: Der Browser hat das Intermediate gecacht, curl nicht → das fehlende Intermediate muss serverseitig ins Zertifikats-Bundle (Fullchain) aufgenommen werden.
- Nach Korrektur erneut prüfen, bis die Kette lückenlos bis zur Root verifiziert.
Anwenden
Ziel ist eine lückenlose Fullchain (Leaf + Intermediates), die bis zu einer vertrauenswürdigen Root verifiziert.
- Füge Leaf und die vorhandenen Intermediate-Zertifikate als PEM ein.
- Lass das Tool die Issuer↔Subject-Verkettung und die Signaturen Stufe für Stufe prüfen.
- Erkenne eine Lücke (fehlendes Intermediate) oder eine gebrochene Signatur und leite die Korrektur ab.
Selbsttest
Praxis-Challenge
Hole dir die Zertifikatskette einer HTTPS-Seite (Browser-Export oder openssl s_client) und prüfe sie im Chain-Checker. Entferne testweise das Intermediate aus der Eingabe und beobachte, wie die Prüfung scheitert. Beschreibe, welche Datei ein Server liefern muss, damit auch strikte Clients (curl) die Kette akzeptieren.