Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- centos:ca-chain [23.02.2015 09:10. ] – angelegt 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 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!