Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
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) ====== | ====== Zertifizierungspfad beim SSL Zertificate (trusted chain) ====== | ||
- | Bei der asymmetrischen Verschlüsselung, | + | Bei der asymmetrischen Verschlüsselung, |
Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, | Bei einer reinen 1:1 Kommunikation können sich beide Kommunikationspartner, | ||
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. | 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. < | ||
+ | issuer= / | ||
+ | - 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**. < | ||
+ | issuer= / | ||
+ | - 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. < | ||
+ | issuer= / | ||
+ | - 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. < | ||
+ | issuer= / | ||
+ | ── (1) Equifax Secure Certificate Authority | ||
+ | │ | ||
+ | └── (2) GeoTrust Global CA | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | - 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)**. < | ||
+ | - Zum Schluss überprüfen wir noch ob nun alle benötigten Zertifikate in der richtigen Reihenfolge vorliegen.< | ||
+ | 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! | ||
+ | </ | ||
- | FIXME |