Wie validiert ein Client eine Zertifikatskette zurück bis zu einer vertrauenswürdigen Wurzel?
Kurzantwort
Der Client baut eine Kette vom Server-Zertifikat (Leaf) über eine oder mehrere Zwischen-CAs bis zu einer Root-CA in seinem Vertrauensspeicher auf. Er verifiziert die Signatur jedes Zertifikats mit dem öffentlichen Schlüssel des nächsten Ausstellers, prüft Gültigkeitsdaten, Name-/Hostname-Übereinstimmung, Schlüsselverwendung und Widerruf (CRL/OCSP). Das Vertrauen endet an einer selbstsignierten, vorab vertrauten Wurzel; die Kette ist nur gültig, wenn jedes Glied stimmt.
Dies ist eine Frage auf Senior-Niveau, denn die Kettenvalidierung ist der Ort, an dem viele reale TLS-Fehler und Fehlkonfigurationen wohnen. Der Interviewer will sehen, dass du verstehst, dass Vertrauen transitiv und verankert ist, nicht magisch.
Die Vertrauenskette
Ein Server präsentiert ein Leaf-Zertifikat für seinen Hostname. Dieses Leaf ist von einer Zwischen-CA signiert, die wiederum von einer Root-CA signiert ist. Die Wurzel ist selbstsigniert und liegt im Vertrauensspeicher des Clients (mit dem Betriebssystem oder Browser ausgeliefert). Die Validierung arbeitet nach oben: Jedes Zertifikat wird mit dem öffentlichen Schlüssel des darüberliegenden Zertifikats verifiziert, bis du eine bereits vertraute Wurzel erreichst. Endet die Kette nicht an einer vertrauenswürdigen Wurzel, scheitert die Validierung.
Wurzeln signieren Zwischenzertifikate statt direkt Leafs, damit der kostbare private Wurzelschlüssel offline bleiben kann; wird ein Zwischenzertifikat kompromittiert, kann es widerrufen werden, ohne die Wurzel zu verbrennen.
Was an jedem Glied geprüft wird
- Signatur – verifiziert der öffentliche Schlüssel des Ausstellers die Signatur dieses Zertifikats?
- Gültigkeitsdaten – liegt das Zertifikat in seinem Not-Before-/Not-After-Fenster?
- Namensübereinstimmung – stimmt das Subject/SAN des Leaf mit dem vom Client angeforderten Hostname überein?
- Schlüsselverwendung / Einschränkungen – darf jede CA tatsächlich ausstellen (Basic Constraints, Pfadlänge)?
- Widerruf – wurde es widerrufen, über eine CRL oder eine OCSP-Abfrage? OCSP-Stapling erlaubt dem Server, einen frischen signierten Status vorzulegen, um einen Client-Roundtrip zu vermeiden.
Häufige Fehlerquellen
Der häufigste reale Bruch ist ein fehlendes Zwischenzertifikat: Der Server sendet nur das Leaf, sodass Clients, die das Zwischenzertifikat nicht zwischengespeichert haben, keinen Pfad zur Wurzel aufbauen können. Weitere sind abgelaufene Zertifikate, Hostname-Diskrepanzen und nicht vertraute (selbstsignierte oder private) Wurzeln.
Worauf Interviewer achten
Der Aufstieg zu einer selbstsignierten, vorab vertrauten Wurzel; die Signaturprüfung bei jedem Sprung; die Gültigkeits-/Hostname-/Widerrufsprüfungen; und das Bewusstsein, warum Zwischenzertifikate existieren und wie ein fehlendes die Kette bricht.
Wahrscheinliche Anschlussfragen
- Warum stellen CAs aus Zwischenzertifikaten aus, statt direkt mit der Wurzel zu signieren?
- Was ist der Unterschied zwischen CRL und OCSP und was ist OCSP-Stapling?
- Was passiert, wenn der Server ein Zwischenzertifikat aus der Kette weglässt?