Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
centos:ca-chain [23.02.2015 10:19. ] djangocentos:ca-chain [10.02.2019 17:58. ] – [Zertifizierungspfad beim SSL Zertificate (trusted chain)] django
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. <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 
  • centos/ca-chain.txt
  • Zuletzt geändert: 13.02.2019 14:12.
  • von django