Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:ca-chain [23.02.2015 10:19. ] – django
+++ centos:ca-chain [13.02.2019 14:12. ] (aktuell) – django
@@ Zeile 1: / Zeile 1: @@
 ====== Zertifizierungspfad beim SSL Zertificate (trusted chain) ======
-Bei der asymmetrischen Verschlüsselung, wie sie bei SSL/TLS gesicherter Kommunikation zum Einsatz kommt, benötigt der sendende Kommunikationspartner den öffentlichen Schlüssel (public key) des Empfängers. Bei dieser Kommunikation ist es äusserst wichtig, dass die Echtheit des Schlüssels gewährleistet, sprich auch überprüft werden kann. Diese Überprüfung erfolgt mit digitalen Zertifikaten, die die Echtheit eines öffentlichen Schlüssels sowie den Geltungsbereich und die Anwendungsbereich für das Zertifikat bestätigen.
+Bei der asymmetrischen Verschlüsselung, wie sie bei SSL/TLS gesicherter Kommunikation zum Einsatz kommt, benötigt der sendende Kommunikationspartner den öffentlichen Schlüssel (public key) des Empfängers. Bei dieser Kommunikation ist es äußerst wichtig, dass die Echtheit des Schlüssels gewährleistet, sprich auch überprüft werden kann. Diese Überprüfung erfolgt mit digitalen Zertifikaten, die die Echtheit eines öffentlichen Schlüssels sowie den Geltungsbereich und die Anwendungsbereich für das Zertifikat bestätigen.
 Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, oder der Client mit dem Server dieses Vertrauen selbst gegenseitig aussprechen. In den allermeisten Fällen wird es aber bei der verschlüsselten und vertraulichen Kommunikation um eine 1:n Kommunikation handeln; d.h. ein Server wird mit unter sehr vielen Clients Daten austauschen. Eine gegenseitige Vertrauensbildung ist hier in den allermeisten Fällen nicht realistisch und praktikabel durchführbar.
@@ Zeile 12: / Zeile 12: @@
 Der Publickey in dem Zertifikat **dokuwiki.nausch.org** wurde mit dem Zertifikat **CAcert Class 3 Root** unterschrieben. Der Publickey dieses Root-Zertifikates **CAcert Class 3 Root** wurde wiederum mit dem Root-Zertifikat **CA Cert Signing Authority** unterschrieben.
-Damit ein Client die Vertrauenskette (trusted chain) überprüfen kann, muss der Server diese beim TLS-Verbindungshandshake mit ausliefern! Normaler Weise wird die ausstellende CA von sich aus immer die benötigten Zwischen- und Root-Zertifikate der (Sub)CAs zur Verfügung stellen.
+Damit ein Client die Vertrauenskette (trusted chain) überprüfen kann, muss der Server diese beim TLS-Verbindungshandshake mit ausliefern! Normaler Weise wird die ausstellende CA von sich aus immer die benötigten Zwischen- und Root-Zertifikate der (Sub)CAs zur Verfügung stellen. Nutzt man einen sehr preisgünstigen Anbieter von Zertifikaten kann, die Suche nach den richtigen und passenden Zertifikaten zuweilen doch recht aufwändig werden.
+Wir werden nun darauf eingehen, wie wir die **trusted chain** ermitteln, die Zertifikate besorgen und überprüfen können.
+Im folgenden Beispiel orientieren wir uns am vorliegendem Zertifikat des Mailservers mx1.nausch.org. Das Zertifikat haben wir von der CA unseres Vertrauens erhalten.
+  - Als erstes ermitteln wir, wer genau unser Zertifikat unterschrieben hat. <code> # openssl x509 -subject -issuer -noout -in mx1.nausch.org.servercert.pem</code><code>subject= /serialNumber=3S7x2lcbYiAccKZPoha0MSwP5hNsuSTP/OU=GT49447951/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.nausch.org
+issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA</code> Der **CN** bei der Zeile **issuer** beschreibt nun das Zertifikat, mit dem unser Serverzertifikat unterschrieben wurde.
+  - Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat **RapidSSL_CA.pem** auf unseren Rechner. \\ \\
+  - Auch bei diesem Root-Zertifikat **RapidSSL_CA.pem** ermitteln wir nun den **issuer**. <code> # openssl x509 -subject -issuer -noout -in RapidSSL_CA.pem</code><code>subject= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
+issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA</code> Das Root Zertifikat der //**RapidSSL CA**// wurde also mit dem Root-Zertifikat der //**GeoTrust Global CA**// signiert.
+  - Wir benötigen also ein weiteres Root-Zertifikat. Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat **GeoTrust_Global_CA.pem** auf unseren Rechner. \\ \\
+  - Nun können wir ermitteln, wer dieses Zertifikat unterschrieben hat. <code> # openssl x509 -subject -issuer -noout -in GeoTrust_Global_CA.pem</code> <code>subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
+issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority</code>Das Root Zertifikat der //**GeoTrust Global CA**// wurde also mit dem Root-Zertifikat der //**Equifax Secure Certificate Authority**// unterschrieben.
+  - Wir werden uns also auch dieses Root-Zertifikat besorgen müssen. Erneiut gehen wir auf die Suche nach dem Root-Zertifikat und laden uns das betreffende Zertifikat **Equifax_Secure_Certificate_Authority.pem** auf unseren Rechner. \\ \\
+  - Auch hier überprüfen wir nun, wer dieses Zertifikat nun unterschrieben hat. <code> # openssl x509 -subject -issuer -noout -in Equifax_Secure_Certificate_Authority.pem</code><code>subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
+issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority</code> Hier sehen wir nun, dass das **subject** und der **issuer** identisch sind, das Zertifikat wurde also selbst signiert (self signed certificate). Wir haben hier also das Wurzelzertifikat unserer Zertifizierungskette. <WRAP center round tip 90%>Somit ergibt sich für unser Zertifikat folgende komplette Zertifizierungskette. <code>
+── (1) Equifax Secure Certificate Authority
+    │
+    └── (2) GeoTrust Global CA
+         │
+         └──  (3) RapidSSL CA
+               │
+               └── (4) mx1.nausch.org.servercert.pem</code>Aus Interoperabilitätsgründen sollte vom Server immer die komplette Zertifikatskette zur Verfügung gestellt werden!</WRAP>
+  - Wir erstellen uns nun eine Datei in der die Root-Zertifikaten vom Serverzertifikat beginnend zum ersten Rootzertifikat beinhaltet, also in unserem Beispiel in der Reihenfolge **(3) -> (2) -> (1)**. <code> # cat RapidSSL_CA.pem GeoTrust_Global_CA.pem Equifax_Secure_Certificate_Authority.pem > rapid_geotrust_equifax_bundle.pem</code>
+  - Zum Schluss überprüfen wir noch ob nun alle benötigten Zertifikate in der richtigen Reihenfolge vorliegen.<code> # openssl verify -verbose -purpose sslserver -CAfile rapid_geotrust_equifax_bundle.pem mx1.nausch.org.servercert.pem</code><code>mx01.nausch.org.servercert.pem: OK</code> <WRAP center round info 80%>
+Wir haben also bei diesem Konfigurationsbeispiel nun neben unserem Zertifikat **mx1.nausch.org.servercert.pem** die zugehörige Zertifikatskette **rapid_geotrust_equifax_bundle.pem** vorliegen!
+</WRAP>
-FIXME