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 ä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.

Für die Überprüfung der Echtheit der zur Verschlüsselung verwendeten X.509-Zertifikates wird wiederum ein digitales Zertifikat einer CA1) 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.

Die nachfolgende Graphik zeigt den Zertifizierungspfad eines Zertifikats mit dem CN2) dokuwiki.nausch.org.

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.

  1. Als erstes ermitteln wir, wer genau unser Zertifikat unterschrieben hat.
     # openssl x509 -subject -issuer -noout -in mx1.nausch.org.servercert.pem
    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

    Der CN bei der Zeile issuer beschreibt nun das Zertifikat, mit dem unser Serverzertifikat unterschrieben wurde.

  2. Von der Webseite der CA laden wir uns nun das betreffende Root-Zertifikat RapidSSL_CA.pem auf unseren Rechner.

  3. Auch bei diesem Root-Zertifikat RapidSSL_CA.pem ermitteln wir nun den issuer.
     # openssl x509 -subject -issuer -noout -in RapidSSL_CA.pem
    subject= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
    issuer= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

    Das Root Zertifikat der RapidSSL CA wurde also mit dem Root-Zertifikat der GeoTrust Global CA signiert.

  4. 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.

  5. Nun können wir ermitteln, wer dieses Zertifikat unterschrieben hat.
     # openssl x509 -subject -issuer -noout -in GeoTrust_Global_CA.pem
    subject= /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

    Das Root Zertifikat der GeoTrust Global CA wurde also mit dem Root-Zertifikat der Equifax Secure Certificate Authority unterschrieben.

  6. 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.

  7. Auch hier überprüfen wir nun, wer dieses Zertifikat nun unterschrieben hat.
     # openssl x509 -subject -issuer -noout -in Equifax_Secure_Certificate_Authority.pem
    subject= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
    issuer= /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

    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.

    Somit ergibt sich für unser Zertifikat folgende komplette Zertifizierungskette.

    ── (1) Equifax Secure Certificate Authority
        │ 
        └── (2) GeoTrust Global CA
             │ 
             └──  (3) RapidSSL CA
                   │ 
                   └── (4) mx1.nausch.org.servercert.pem

    Aus Interoperabilitätsgründen sollte vom Server immer die komplette Zertifikatskette zur Verfügung gestellt werden!

  8. 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).
     # cat RapidSSL_CA.pem GeoTrust_Global_CA.pem Equifax_Secure_Certificate_Authority.pem > rapid_geotrust_equifax_bundle.pem
  9. Zum Schluss überprüfen wir noch ob nun alle benötigten Zertifikate in der richtigen Reihenfolge vorliegen.
     # openssl verify -verbose -purpose sslserver -CAfile rapid_geotrust_equifax_bundle.pem mx1.nausch.org.servercert.pem
    mx01.nausch.org.servercert.pem: OK

    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!


1)
Certificate Authority
2)
Common Name
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/ca-chain.txt
  • Zuletzt geändert: 13.02.2019 14:12.
  • von django