Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:ca-chain [23.02.2015 09:10. ] – angelegt django
+++ centos:ca-chain [10.02.2019 17:58. ] – [Zertifizierungspfad beim SSL Zertificate (trusted chain)] django
@@ Zeile 6: / Zeile 6: @@
 Für die Überprüfung der Echtheit der zur Verschlüsselung verwendeten X.509-Zertifikates wird wiederum ein digitales Zertifikat einer **CA**((**C**ertificate **A**uthority)) oder kurz Zertifizierungsstelle verwendet. Diese CA bestätigt somit die Echtheit des Zertifikates. Eine Zertifikat (Root Zertifikat) einer CA selbst kann wiederum durch eine weitere **CA** beglaubigt worden sein. Somit ergibt sich eine Kette von Zertifikaten, bei der jedes Zertifikat mit dem Zertifikat der übergeordneten Stelle authentifiziert werden kann. Diese Vertrauenskette wird auch Zertifizierungspfad oder **//trusted chain//** bezeichnet.
-{{ :centos:zertifikats-kette.png?direct&400 |Bild: Zertifikatskette eines Zertifikates (Firefox)}}
+Die nachfolgende Graphik zeigt den Zertifizierungspfad eines Zertifikats mit dem **CN**((**C**ommon **N**ame)) //**dokuwiki.nausch.org**//.
+{{ :centos:zertifikats-kette.png?direct&350 |Bild: Zertifikatskette eines Zertifikates (Firefox)}}
+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. 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!