Soll die CA.crt beim Erstellen selbstsignierter Zertifikate auf dem Clientcomputer installiert werden?

Die Vertrauenskette selbst kann anhand der Zertifikatstruktur erklärt werden.

Wenn wir vom Zertifikat Ihres Servers ausgehen (d. h das Zertifikat, das Sie normalerweise für Apache verwenden würden):

• Ihr Serverzertifikat wird von einer Zertifizierungsstelle basierend auf einer von Ihnen bereitgestellten CSR generiert. Diese CSR enthält Ihren öffentlichen Schlüssel und einige andere Informationen, an deren Verwendung die Zertifizierungsstelle möglicherweise interessiert ist oder nicht.
• Die Zertifizierungsstelle empfängt Ihre CSR und erstellt (im Allgemeinen) ein signiertes Zertifikat unter Verwendung einer Zwischenzertifizierungsstelle. Ihr Zertifikat verfügt über zwei öffentliche Schlüssel: einen für den Betreff (der aus Ihrem CSR extrahierte öffentliche Schlüssel) und einen für die ausstellende Partei, bei der es sich um das Zwischenzertifikat der Zertifizierungsstelle handelt.
• die Zertifizierungsstelle Das Zwischenzertifikat selbst ist ein signiertes Zertifikat (mit einigen speziellen Optionen), bei dem der Betreffschlüssel der öffentliche Schlüssel der Zwischenzertifizierungsstelle ist (der der gleiche öffentliche Schlüssel ist, der im öffentlichen Schlüssel des Ausstellers Ihres Serverzertifikats enthalten ist) Der signierende (oder ausstellende) Schlüssel ist das Stammzertifikat der Zertifizierungsstelle (alternativ ist es ein anderes Zwischenprodukt).
• Das Stammzertifikat der Zertifizierungsstelle ist (im Allgemeinen) ein selbstsigniertes Zertifikat. In der Praxis bedeutet dies, dass der Aussteller- und der Betreffschlüssel derselbe öffentliche Schlüssel sind.

Sie können dies sehen, indem Sie Zertifikate in freier Wildbahn überprüfen, z. B.:

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

Die Vertrauenskette, die dies aufbaut, kann wie folgt zusammengefasst werden: (Ich gehe von der “ bottom „- das Equifax-Zertifikat):

• Die Stammzertifizierungsstelle (Equifax) delegiert die täglichen Aktivitäten an eine Zwischenzertifizierungsstelle (GeoTrust) und signiert ein Zertifikat, das diese Tatsache darstellt (dh die Festlegung der Zertifizierungsstelle: TRUE, KeyUsage: keyCertSign) Mit anderen Worten, die Stammzertifizierungsstelle „vertraut“ dem Zwischenprodukt, um in seinem Namen Zertifikate auszustellen (hoffentlich nach Abschluss einer Reihe obligatorischer Validierungsschritte).
• in dieser Kette das Zwischenprodukt (Geotrust) hat weiter an eine Google-Zertifizierungsstelle delegiert (CN = Google Internet Authority G2).
• Der Delegierte (auch bekannt als Google-Zwischenzertifizierungsstelle) unterzeichnet dann eine CSR, die effektiv ein Dokument ist, das dies für eine bestimmte Person angibt Satz von Namen (t Der CN und möglicherweise der Betreff Alternative Namen), ein privates / öffentliches Schlüsselpaar, ist gültig / vertrauenswürdig (das Vertrauen ergibt sich aus der Tatsache, dass sie den Anspruch bestätigt haben, für einen bestimmten Namen zu sprechen – in diesem Fall hat die Google-Zertifizierungsstelle eine ausgestellt Zertifikat für * .google.com).

Beachten Sie, dass (Stamm-) Zertifizierungsstellen im Allgemeinen selbst signiert sind. Eine Zertifizierungsstelle ist im Allgemeinen vertrauenswürdig, da sie eine Reihe von Prozessen und Verfahren einhält, mit denen sichergestellt werden soll, dass keine Zertifikate an Personen ausgestellt werden wer sollte sie nicht haben. Aus diesem Grund kann ich mir kein Zertifikat besorgen, aus dem hervorgeht, dass ich Google bin.Dies ist daher eine Art Konvention (wenn auch eine, die durch formale Mechanismen unterstützt wird). Wenn Sie eine eigene Zertifizierungsstelle starten, erreicht das Verteilen der Stammzertifikate (und Zwischenzertifikate) genau das Gleiche wie das Verteilen der Zertifikate anderer Zertifizierungsstellen: Es werden Zertifikate ausgestellt von dieser Zertifizierungsstelle vom System als gültig (dh vertrauenswürdig) akzeptiert werden.

Praktischer ausgedrückt besteht der Trust Store (für openSSL) aus einer Reihe von Dateien mit einer bestimmten Namenskonvention. Siehe https://www.openssl.org/docs/faq.html#USER5 :

Wann Ein Zertifikat wird überprüft, ob seine Stammzertifizierungsstelle von OpenSSL „vertrauenswürdig“ ist. Dies bedeutet normalerweise, dass das Zertifizierungsstellenzertifikat in einem Verzeichnis oder einer Datei abgelegt und das entsprechende Programm zum Lesen konfiguriert werden muss.

Dieses Verzeichnis ist / etc / ssl / certs (es gibt andere, wie / etc / pki auf RH-Likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 bietet einen weiteren Überblick darüber, wie man dem Geschäft ein Zertifikat hinzufügt tut https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

Die Kurzversion lautet update-ca-certificates automatisiert den Prozess und ist das häufig verwendete Tool.

Die etwas längere Version ist, dass Zertifikate per Hash gespeichert werden müssen (z. B. in Dateien, deren Namen basieren auf der Ausgabe von openssl x509 -hash -in cert.pem), damit openSSL Ketten effizient validieren kann.

Siehe https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html für zusätzlichen Hintergrund.

aktualisiert, um auf die Fragen in Kommentaren zu antworten:

Das Serverzertifikat wird in dieser Diskussion als vertrauenswürdig definiert oder nicht basierend auf seiner Vertrauenskette. Wenn Sie darüber nachdenken, wie (z. B.) curl https://google.com funktioniert, ist es etwas einfacher zu verstehen:

• curl öffnet eine TLS-Verbindung zu Google, die zurückgegeben wird ein Zertifikat.
• curl überprüft dieses „Endbenutzer“ -Zertifikat – dh das Zertifikat des Servers – und sucht speziell nach dem Aussteller.
• wenn der Aussteller in „bekannt“ ist Im Trust Store wird der Rest der Vertrauenskette validiert (dh das Zertifikat des Ausstellers des Serverzertifikats wird überprüft, und wenn es einen anderen Aussteller als sich selbst hat, wird dieser Aussteller überprüft usw.). Nur wenn die vollständige Vertrauenskette validiert werden kann, wird das Zertifikat als gültig angesehen.

Es wäre jedoch absolut unpraktisch, Vertrauensketten zu verteilen, wenn Endbenutzerzertifikate enthalten sein müssten. Ich habe keine Zahlen darüber, wie viele Websites es gibt, aber basierend auf der Tatsache, dass Alexa eine Top-1M liefert, würden Sie annehmen, dass es mehr als 1 Million sind.

Worum geht es? Eine Vertrauenskette: Im Allgemeinen müssen die Ausstellerzertifikate vorhanden sein, aber die Endzertifikate müssen nicht verteilt werden, da sie Ihnen mitteilen, wer der Aussteller ist.

Und Sie können überprüfen, ob sie nicht vorhanden sind. “ Dies liegt daran, dass Sie den öffentlichen Schlüssel des Ausstellers (und die Vertrauenskette, die ihn als richtigen Schlüssel festlegt) überprüfen und überprüfen können, ob das Endbenutzerzertifikat (dh der Serverzertifikat) wirklich vom privaten Gegenstück des Ausstellers signiert wurde öffentlicher Schlüssel.

Nein, Sie sollten also nicht die Endbenutzerzertifikate verteilen, sondern nur die Vertrauenskette – oder einfacher ausgedrückt: Verteilen Sie alle Zertifikate, die Sie wo generieren Die BasicConstraints sagen (zu Recht) mindestens etwas CA: TRUE. Verteilen Sie nichts, was diese Bedingung nicht erfüllt, da dies eine Verschwendung von Zeit und Speicherplatz ist – Alles, was nicht CA: TRUE sagt, kann gegen etwas validiert werden, das dies tut.

Kommentare

• Bedeutet dies in jedem Fall, dass der Client Zugriff auf das Stammzertifizierungsstellenzertifikat oder nur auf das Zertifizierungsstellenzertifikat benötigt, von dem der Server Zertifikat wurde unterschrieben von? Oder fehlt mir noch ein Punkt vollständig?
• Um das Serverzertifikat zu überprüfen, benötigen die Clients Zugriff auf die vollständige Vertrauenskette für dieses Zertifikat. Andernfalls betrachtet der Client das Zertifikat entweder als ungültig oder fordert den Benutzer auf, es zu akzeptieren. In Ihrem Fall ist es ziemlich wahrscheinlich, dass Sie keinen Verteilungspunkt für Ihre CA / CRLs einrichten. Der einfachste Weg besteht darin, sicherzustellen, dass sich Ihre Zertifikate in / etc / ssl / certs auf Clientcomputern befinden. tl; dr: Ein Zertifikat wird nur begrenzt zur Herstellung von Vertrauen verwendet, wenn Sie ' seine Vertrauenskette nicht herstellen können. Und Sie müssen die gesamte Kette validieren, um dies festzustellen. Stellen Sie also die gesamte Vertrauenskette zur Verfügung.
• Bedeutet dies, dass auf dem Server eine Stammzertifizierungsstelle, eine Zwischenzertifizierungsstelle und das signierte Zertifikat vorhanden sind. Alle drei dieser Zertifikate müssen dem Client innerhalb des /etc/ssl/certs Verzeichnis? Da diese alle die öffentlichen Schlüssel enthalten?