Zertifikatsketten

Eine Zertifikatskette (oder Vertrauenskette) ist die geordnete Liste von Zertifikaten, die das Leaf-Zertifikat eines Servers mit einem vertrauenswürdigen Root-Zertifikat verbindet.

Jedes Zertifikat wird von dem darüber stehenden Zertifikat signiert.

Eine typische Kette besteht aus drei Teilen:

• Leaf-Zertifikat (End-Entity-Zertifikat) für den eigentlichen Server.
• Zwischenzertifikate, die das Leaf-Zertifikat signiert haben.
• Root-Zertifikat, das das Zwischenzertifikat signiert hat.

Zur Validierung prüft ein Client jede Signatur von unten nach oben:

• Mit dem öffentlichen Schlüssel des Root-Zertifikats wird das Zwischenzertifikat verifiziert.
• Mit dem öffentlichen Schlüssel des Zwischenzertifikats wird das Leaf-Zertifikat verifiziert.

Wenn jede Signatur erfolgreich geprüft wird und die Kette bei einem vertrauenswürdigen Root endet, ist sie gültig.

Sie können die Zertifikatskette anzeigen, die ein Server präsentiert, indem Sie OpenSSLs s_client verwenden.

Ketten werden durch übereinstimmende Felder verknüpft: Der Issuer eines Zertifikats entspricht dem Subject des darüberliegenden Zertifikats.

Ein sehr häufiger Fehler besteht darin, dass ein Server nur sein Leaf-Zertifikat sendet und das Zwischenzertifikat vergisst.

Einige Clients können dann keinen Pfad zum Root aufbauen und melden ein nicht vertrauenswürdiges Zertifikat, obwohl technisch alles gültig ist.

Server sollten das Leaf-Zertifikat zusammen mit allen Zwischenzertifikaten senden, normalerweise jedoch nicht das Root-Zertifikat, das die Clients bereits besitzen.

Diese kombinierte Datei wird häufig fullchain.pem genannt.

Sie können eine Kette lokal verifizieren, indem Sie das vertrauenswürdige Root-Zertifikat angeben.

Bei der Validierung geht es um mehr als nur Signaturen. Der Client prüft außerdem:

• Jedes Zertifikat ist innerhalb seiner Gültigkeitsdauer gültig.
• Kein Zertifikat der Kette ist widerrufen.
• Bei CA-Zertifikaten ist in den Basic Constraints das CA-Flag gesetzt.
• Schlüsselverwendung und Namensbeschränkungen werden eingehalten.

Manchmal ist ein neuer Root noch nicht überall vertrauenswürdig. Durch Cross-Signing kann ein älterer, weit verbreitet vertrauenswürdiger Root auch das neue Zwischenzertifikat signieren.

Dadurch entstehen mehrere gültige Pfade, was die Kompatibilität mit älteren Geräten verbessert.

Häufige Fehler bei Zertifikatsketten sind:

• Fehlendes Zwischenzertifikat
• Abgelaufenes Zertifikat an beliebiger Stelle im Pfad
• Falsche Reihenfolge in der Kettendatei
• Nicht vertrauenswürdiger oder explizit abgelehnter Root

Ein Server präsentiert nur sein Leaf-Zertifikat, und einige Clients melden es als nicht vertrauenswürdig. Was ist die wahrscheinlichste Ursache?

Sie haben gelernt, wie eine Zertifikatskette ein Leaf-Zertifikat über Zwischenzertifikate mit einem vertrauenswürdigen Root verknüpft.

• Die Validierung durchläuft die Kette und prüft jede Signatur, die Gültigkeitsdaten und den Widerrufsstatus.
• Server sollten die vollständige Kette senden, um Fehler durch fehlende Zwischenzertifikate zu vermeiden.
• Cross-Signing verbessert die Kompatibilität.

Als Nächstes behandeln wir die praktischen Aufgaben der Zertifikatsverwaltung.