it-swarm.com.de

SSL-Stammzertifikat optional?

Möglicherweise hatte ich den falschen Eindruck, wie Server eingerichtet werden sollten und welche Zertifikate tatsächlich während der Hallo-Zertifikat-Nachricht des Servers gesendet werden. Ich bin heute von Symantec/VeriSign darauf gestoßen:

Root auf dem Server installiert. Entfernen Sie für bewährte Methoden das selbstsignierte Stammverzeichnis vom Server. Das Zertifikatspaket sollte nur den öffentlichen Schlüssel des Zertifikats und den öffentlichen Schlüssel aller zwischengeschalteten Zertifizierungsstellen enthalten. Browser vertrauen nur Zertifikaten, die in Roots aufgelöst werden, die sich bereits in ihrem Trust Store befinden. Sie ignorieren ein im Zertifikatspaket gesendetes Root-Zertifikat (andernfalls kann jeder Root senden).

Wenn dies zutrifft und das Stammzertifikat nicht auf dem Server installiert werden muss, gibt es das, was ich über die ordnungsgemäße Servereinrichtung zu wissen glaubte und wie die Kette zum Stamm zurück validiert wird. Andererseits, wenn ich auf diese Frage zurückblicke, im Abschnitt Zertifikate und Authentifizierung von Antwort von Thomas Pornin heißt es:

Der Client soll also Folgendes tun:

  • Holen Sie sich eine Zertifikatskette, die mit dem Zertifikat des Servers endet. Die Zertifikatnachricht vom Server soll genau eine solche Kette enthalten.

Dies sagt so ziemlich das Gegenteil der obigen Symantec/VeriSign-Nachricht aus, es sei denn, ich verstehe etwas falsch. Damit:

  1. Muss auf einem Server die gesamte Kette einschließlich des Stamms installiert sein? Wenn nicht, womit vergleicht ein Browser die Validierung, da der Server während des Handshakes sein Stammzertifikat nicht bereitstellt? Schaut es sich einfach das Identitätszertifikat an und holt es sich von dort? (Sie möchten beispielsweise ein Identitätszertifikat auf Ihrem lokalen Computer öffnen und die gesamte Kette im Zertifizierungspfad sehen?)

  2. Wenn dies zutrifft, was ist dann mit eigenständigen Client-Apps, die SSL-Bibliotheken verwenden? Hängt dies von der Anwendung ab, da sie möglicherweise andere Methoden zur Pfadbildung zu einem vertrauenswürdigen Stamm als zu einem Browser hat?

26
user53029

Der Server sendet immer eine Kette. Gemäß TLS-Standard kann die Kette das Stammzertifikat selbst enthalten oder nicht. Der Client benötigt diese Wurzel nicht, da er sie bereits hat. Und in der Tat, wenn der Client noch nicht über das Stammverzeichnis verfügt, hilft es nicht, es vom Server zu empfangen, da einem Stammverzeichnis nur dadurch vertraut werden kann, dass es bereits vorhanden ist.

Was Symantec sagt, ist, dass sie empfehlen, nicht die Wurzel zu senden, sondern nur den Rest der Kette. Dies ist sinnvoll: Da der Root für Validierungszwecke unbrauchbar ist, können Sie das Senden auch vermeiden und etwa 1 KB Datenbandbreite pro Verbindung speichern.

Wie auch immer:

  • Das Zertifikat des Servers mit seiner Kette ist nicht für den Server bestimmt. Der Server hat keine Verwendung für sein eigenes Zertifikat. Zertifikate sind immer für andere Personen (hier der Kunde). Was vom Server verwendet wird, ist sein privater Schlüssel (der dem öffentlichen Schlüssel in seinem Zertifikat entspricht). Insbesondere muss der Server kein eigenes Zertifikat oder eine Zertifizierungsstelle, die ihn ausgestellt hat, vertrauen.

  • In TLS soll der Server eine Kette senden. und der Client soll irgendwie den öffentlichen Schlüssel des Servers für den Handshake verwenden. Dem Client steht es frei, diesen öffentlichen Schlüssel auf jede gewünschte Weise zu "kennen", obwohl natürlich erwartet wird, dass der Client den öffentlichen Schlüssel des Servers aus der Zertifikatkette erhält, die der Server gerade gesendet hat. Browser versuchen in erster Linie, die vom Server gesendete Kette zu verwenden (indem sie versuchen, sie unter einem der Wurzeln zu verknüpfen, denen der Browser bereits vertraut). Im Fehlerfall versuchen sie, andere Ketten auf der Grundlage von CA-Zwischenzertifikaten zu erstellen, die sie bereits kennen oder die sie im laufenden Betrieb herunterladen können.

    In eigenständigen Anwendungen können Anwendungsschreiber diesen Schritt auf beliebige Weise konfigurieren oder umgehen. Dies kann hilfreich sein, wenn der öffentliche Schlüssel des Servers im Anwendungscode fest codiert werden kann (in diesem Fall wird die vom Server gesendete Kette einfach vollständig ignoriert ). Leider ist die Freiheit, einen benutzerdefinierten Schritt zur Validierung von Zertifikaten zu implementieren, auch die Freiheit, die Sicherheit zu überwachen, zu erstechen und dann die Leiche in einen Graben zu werfen. Es kommt viel zu oft vor.

29
Thomas Pornin

womit vergleicht ein Browser zur Validierung, da der Server während des Handshakes sein Stammzertifikat nicht bereitstellt?

Die gesamte Idee der Zertifikatsprüfung besteht darin, dass die Clients über einige vertrauenswürdige Stammzertifikate verfügen (im Lieferumfang des Browsers oder des Betriebssystems enthalten) und dass das vom Browser gesendete Zertifikat anhand dieses lokalen Vertrauensankers überprüft wird.

Dies bedeutet, dass der Server das Stammzertifikat nicht an den Client senden muss (und sollte), da sich dieses Stammzertifikat bereits am Ende des Clients befinden soll. Wenn das Stammzertifikat weiterhin gesendet wird, verwirft der Client es einfach, d. H. Er vertraut keinem vom Server gesendeten Stammzertifikat.

Wenn dies zutrifft, was ist dann mit eigenständigen Client-Apps, die SSL-Bibliotheken verwenden? Hängt dies von der Anwendung ab, da sie möglicherweise andere Methoden zur Pfadbildung zu einem vertrauenswürdigen Stamm als zu einem Browser hat?

Der grundlegende Überprüfungsprozess zwischen Browsern und SSL-Bibliotheken ist der gleiche. Es gibt einige Unterschiede beim Erstellen von Pfaden in Edge-Fällen zwischen openssl und Browsern (siehe http://rt.openssl.org/Ticket/Display.html?id=2732&user=guest&pass=guest ) und der Überprüfung Der Hostname des Ziels gegen die Namen im Serverzertifikat ist häufig fehlerhaft oder sogar außerhalb der gängigen Browser nicht vorhanden.

6
Steffen Ullrich

Ich sende die Wurzel, wenn es zweckmäßig ist.

Wenn der Client dem Root vertraut, spielt es keine Rolle, ob Sie ihn senden oder nicht.

Wenn der Client den Stamm nicht erkennt, erzeugt der MS Windows-Client meiner Erfahrung nach weniger verwirrende Diagnosemeldungen, wenn der nicht vertrauenswürdige Stamm in der Kette bereitgestellt wurde.

Wie es weiß, welche Wurzel zu verwenden ist, wenn keine bereitgestellt wird, enthält die neben der Wurzel (die sich in der bereitgestellten Kette befinden muss) die identifizierenden Informationen für die Wurzel, die der Client verwendet, um die Wurzel in der Wurzel nachzuschlagen Geschäft des Kunden.

5
jjanes

Berücksichtigen Sie, dass es Serversoftware (wie IBM HTTP Server) gibt, die startet nicht überhaupt, wenn die Stammzertifizierungsstelle nicht im Keystore enthalten ist.

2
NuTTyX