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.
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.
# 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.
# 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.
# 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.
# 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!
# cat RapidSSL_CA.pem GeoTrust_Global_CA.pem Equifax_Secure_Certificate_Authority.pem > rapid_geotrust_equifax_bundle.pem
# 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!