Was ist die Certificate Chain of Trust?

Der Internet-Sicherheitsstandard SSL/TLS basiert auf einem Vertrauensbeziehungsmodell, auch "certificate chain of trust" genannt.

Digitale x.509-Zertifikate bestätigen die Identität einer Website, einer Organisation oder eines Servers und bieten dem Benutzer eine vertrauenswürdige Plattform für die sichere Verbindung und den sicheren Austausch von Informationen.

SSL/TLS Internet-basierte Public Key Infrastructure (PKI) ermöglicht es Benutzern, Daten unter Verwendung von öffentlichen und privaten Schlüsselpaaren auszutauschen, die von einer vertrauenswürdigen Zertifizierungsstelle (CA) bezogen und ausgetauscht werden. Diese seriöse Einrichtung ist für die Ausstellung, Aufbewahrung und den Widerruf von Zertifikaten für öffentliche Schlüssel über unsichere Netze zuständig.

Wenn Sie eine Website über eine sichere Verbindung besuchen, sendet die Website ein digitales Zertifikat an Ihren Browser. Ihr Internet-Browser vergleicht den Aussteller mit einer Liste von vertrauenswürdigen Zertifizierungsstellen(Root CA). Kann keine Übereinstimmung gefunden werden, prüft der Client-Browser, ob eine vertrauenswürdige Stammzertifizierungsstelle das Zertifikat der ausstellenden Zertifizierungsstelle signiert. Die Verkettungsmaschine des Browsers überprüft den Aussteller jedes Zertifikats so lange, bis sie eine vertrauenswürdige Stammzertifizierungsstelle findet oder das Ende der Vertrauenskette erreicht.

Mit der Vertrauenskettenzertifizierung soll nachgewiesen werden, dass ein bestimmtes Zertifikat aus einer vertrauenswürdigen Quelle stammt.

Wenn das Zertifikat legitim ist und auf eine Root-CA im Truststore des Client-Browsers verweist, weiß der Benutzer anhand der Vertrauensindikatoren der Schnittstelle, dass die Website sicher ist (siehe unten).

Vertrauensindikatoren für Webbrowser

Nehmen wir jedoch an, dass die Überprüfung der Vertrauenskette fehlschlägt. In diesem Fall kann ein Zertifikat seine Gültigkeit nicht allein beweisen, und der Browser warnt den Benutzer vor einem potenziellen Sicherheitsrisiko, wie unten dargestellt.

Warnung vor ungesicherten Websites im Webbrowser

Private PKI-Zertifikate werden jedoch von den wichtigsten Betriebssystemen, Webbrowsern oder Anwendungen nicht allgemein als vertrauenswürdig angesehen. Sie können zwar intern X.509-Zertifikate ausstellen, aber nur Zertifikate von einer öffentlich vertrauenswürdigen Zertifizierungsstelle können verhindern, dass der Browser Warnmeldungen sendet.

Es gibt drei grundlegende Arten von Einheiten, die eine gültige Vertrauenskette bilden: Wurzel-, Zwischen- und Endinstanz. Im nächsten Abschnitt werden wir uns jede einzelne näher ansehen.

Ein Stammzertifikat ist ein selbstsigniertes Zertifikat, das den Standards des X.509-Zertifikats entspricht. Eine mehrstufige hierarchische Vertrauenskette ermöglicht es Web-Clients und -Anwendungen zu überprüfen, ob eine vertrauenswürdige Quelle die Identität des Endteilnehmers bestätigt hat.

Wenn der private Schlüssel des Vertrauensankers kompromittiert ist, sind alle unter diesem privaten Schlüssel signierten Zertifikate kompromittiert und alle von dieser CA ausgestellten Zertifikate betroffen. Dies führt zur Neuausstellung neuer Zertifikate durch die CA für jede zwischengeschaltete CA und Endstelle in der Zertifikatskette.

Daher muss die Stammzertifizierungsstelle ihren privaten Schlüssel genau überwachen und Zertifikate von Endteilnehmern nur selten direkt signieren. Stattdessen erstellt und signiert die Stammzertifizierungsstelle eine oder mehrere Zwischenzertifizierungsstellen, um Zertifikate auszustellen und sie mit der Stammzertifizierungsstelle zu verknüpfen.

Mindestens ein Zwischenzertifikat ist fast immer in einer SSL Zertifikatskette vorhanden. Sie sind ein wichtiges Bindeglied, das es der Root CA ermöglicht, ihren vertrauenswürdigen Ruf auf ansonsten nicht vertrauenswürdige Endeinheiten auszudehnen.

Die ausstellende CA fungiert als Vermittler zwischen dem sicheren Root- und dem Serverzertifikat. Dadurch kann die Root-CA sicher offline gespeichert bleiben, was eine zusätzliche Sicherheitsstufe darstellt.

Das Vertrauen in die Stammzertifizierungsstelle ist immer explizit. Jedes Betriebssystem, jeder Webbrowser eines Drittanbieters und jede benutzerdefinierte Anwendung wird mit über 100 vorinstallierten vertrauenswürdigen Root-CA-Zertifikaten ausgeliefert. Im Gegensatz dazu sind Nicht-Root-Zertifikate implizit vertrauenswürdig und müssen nicht mit einem Betriebssystem, Webbrowser oder einer zertifikatsfähigen Anwendung ausgeliefert werden.

Serverzertifikate bieten Sicherheit, Skalierbarkeit und die Einhaltung von CA-Standards. Zertifikate garantieren jedoch nicht, dass das Subjekt vertrauenswürdig, seriös im Geschäftsverkehr, gesetzeskonform oder sicher in der Geschäftsbeziehung ist.

Die Endstelle übermittelt der ausstellenden Zertifizierungsstelle wichtige Informationen über ein Formular für eine Zertifikatsanforderung (Certificate Signing Request). Das Zertifikat wird dann von einer vertrauenswürdigen Zertifizierungsstelle signiert und ausgestellt, wodurch bestätigt wird, dass die angegebenen Informationen zum Zeitpunkt der Ausstellung korrekt waren. Die SSL Verbindung zu einem Server schlägt fehl, wenn das Zertifikat nicht überprüft und signiert wurde.

Server-Zertifikat-Abonnenten sind nicht immer die Partei des Zertifikats; die Verwendung von Fällen variiert je nach den Anforderungen der Zertifikatsumgebung. Das Zertifikat, das einer Organisation für ihre Mitarbeiter ausgestellt wurde, verifiziert nur, dass die CA die angeforderten Informationen von einem Vertreter dieser Organisation authentifiziert hat, nicht von jedem Mitarbeiter.

So kann eine Root CA beispielsweise Zertifikate ausstellen, die eine bestimmte Rolle des Abonnenten und nicht eine bestimmte Person identifizieren (z. B. ist der "Chief Information Officer" eine eindeutige Person, der "IT-Mitarbeiter" hingegen nicht). Diese Art von rollenbasierten Zertifikaten wird verwendet, wenn Nichtabstreitbarkeit erwünscht ist.

Die Root CA kann auch ein Gruppenzertifikat ausstellen, wenn mehrere Abonnenten ein Zertifikat mit privatem Schlüssel gemeinsam nutzen.

Wenn mehrere Stellen in einer Eigenschaft handeln, muss die CA eine Liste der Teilnehmer führen, die Zugang zum privaten Schlüssel haben, und den Zeitraum aufzeichnen, in dem jeder Teilnehmer die Kontrolle über den Schlüssel hat.

Zertifizierungsstellen können Funktionen sowohl im Zusammenhang mit privaten PKI-Diensten als auch mit dem Betrieb öffentlicher Schlüssel wahrnehmen, einschließlich des Empfangs entsprechender Zertifikatsanträge, der Ausstellung, des Widerrufs und der Erneuerung digitaler Zertifikate.

Sie haben vielleicht bemerkt, dass Zwischen-CAs funktionell ähnlich wie Root-CAs sind. Allerdings sind bei ihnen oft weniger Schlüsselnutzungsfunktionen aktiviert. Ein gültiges X.509-Zertifikat eines vertrauenswürdigen Ausstellers ist nur für die in den Zertifikatsrichtlinien angegebene Verwendung gültig. Zertifikate, die diesen Kettenrichtlinienregeln entsprechen, können für andere Verwendungszwecke mit Funktionen wie Sicherheit / MIME (SMIME), Authenticode oder Secure Sockets Layer (SSL) ungültig sein. Es kann eine weitere Verarbeitung erforderlich sein, um festzustellen, ob das Zertifikat für eine bestimmte Richtlinie gültig ist.

Das Zwischenzertifikat enthält Schlüsselverwendungserweiterungen, die die möglichen Verwendungen oder Zwecke des Zertifikats definieren.

Der Zweck des Zertifikats kann eine der vier Schlüsselverwendungseinstellungen und erweiterten Schlüsselverwendungsfelder sein, die im Zertifikat angegeben sind:

• Verschlüsselung: Zu diesem Zweck werden kryptographische Schlüssel zur Ver- und Entschlüsselung in ein Zertifikat aufgenommen.
• Unterschrift: Das Zertifikat für diesen Zweck enthält nur kryptografische Schlüssel zum Signieren von Daten.
• Signatur und Verschlüsselung: Ein Zertifikat für diesen Zweck muss alle primären Verwendungszwecke des kryptografischen Schlüssels des Zertifikats abdecken, einschließlich Datenverschlüsselung, Datenentschlüsselung, Erstanmeldung oder digitale Signatur.
• Signaturanmeldung und Smartcard-Anmeldung: Das Zertifikat für diesen Zweck ermöglicht die Erstanmeldung der Smartcard und das digitale Signieren der Daten; es kann nicht zur Datenverschlüsselung verwendet werden.

Es gibt eine Root-CA und eine oder mehrere untergeordnete CAs. Die untergeordneten CAs sorgen für Redundanz und Lastausgleich, während die Root-CA normalerweise offline ist. Selbst wenn die untergeordnete CA kompromittiert ist, kann die Root-CA die untergeordnete CA widerrufen und so für Redundanz sorgen.

Es wird auch als Cross-Certification-Modell bezeichnet. CAs bilden hier eine Peer-to-Peer-Beziehung. Die Verwaltung dieses Modells ist eine Herausforderung, wenn die Anzahl der CAs steigt. Diese Art von Vertrauensverhältnis kann entstehen, wenn verschiedene Unternehmensbereiche unterschiedliche CAs haben und diese zusammenarbeiten müssen.

Die Bridge CA überwindet die Komplexität des Web of Trust-Modells. Hier fungiert die Bridge CA als zentrale Koordinierungsstelle. Alle anderen CAs (so genannte Principals) müssen nur der Bridge CA vertrauen.

Das Root-CA-Zertifikat wird durch Neuaufbau des Zertifizierungspfads gefunden. Wenn ein Computer während des Zertifikatsvalidierungsprozesses mehrere vertrauenswürdige Zertifizierungspfade findet, sucht die Certificate Chain Engine nach dem besten Zertifizierungspfad, indem sie die Punktzahl für jede Kette berechnet. Die Punktzahl wird auf der Grundlage der Qualität und Quantität der Informationen berechnet, die der Zertifikatspfad liefern kann. Wenn die Punktzahlen für mehrere Zertifizierungspfade gleich sind, wird die kürzeste Kette ausgewählt.

Das Windows-Betriebssystem ermöglicht die folgenden vier Methoden zum Abrufen von Zertifikaten aus Zertifikatsketten:

1. Über den örtlichen Gutscheinshop;
2. Verwenden Sie einen PKCS#7-Container mit einer vollständigen oder teilweisen Kette;
3. Verwenden Sie die Erweiterung der Erweiterung "Authority Information Access" (AIA);
4. Crypt32.dll und die Website für Microsoft Update.

Schauen wir uns jede dieser Methoden genauer an.

Die CryptoAPI verwendet die lokale Zertifikatspeichersuche, um das benötigte Zertifikat zu erhalten, was die Zeit für den Aufbau der Zertifikatskette verkürzt. Dies gilt jedoch nur für CA-Zertifikate, die bereits von einem Anwendungsanbieter (z. B. einem Betriebssystem oder einem Browserhersteller) installiert wurden. Wenn der lokale Zertifikatspeicher die erforderlichen Zertifikate nicht enthält, werden andere Methoden zum Abrufen von Zertifikaten versucht.

Die Abrufmethode für PKCS#7-Zertifikate ist im Internet weit verbreitet. Eine PKCS#7-Nachricht kann mehrere Zertifikate speichern und als Zertifikatscontainer fungieren. Diese Methode ermöglicht es Serveranwendungen, den Aufbau einer Zertifikatskette zu vereinfachen, indem sie ein vollständiges oder teilweises Zertifikat der Zertifikatskette liefern. Die wichtigsten Webserver, Apache und Microsoft IIS, senden standardmäßig alle Zertifikate, und es ist keine zusätzliche Konfiguration erforderlich, um PKCS#7 zu unterstützen.

Ein ähnliches Verhalten kann bei der Untersuchung der Signaturen von Authenticode beobachtet werden. Beim Signieren einer Binärdatei kann eine Zertifikatskette in die Signatur aufgenommen werden, und diese Zertifikate werden verwendet, um eine Kette zu erstellen, indem jede Signatur validiert wird. Obwohl diese Methode vorteilhaft ist, steht sie nicht immer für Anwendungen zur Verfügung. Bei einer Verbindung zum SSTP-VPN sendet der VPN-Server beispielsweise keine Zwischenzertifikate an den Client.

Wenn Ihr Computer mit dem Internet verbunden ist, überprüft die Certificate Chain Engine die Microsoft Update-Website. Wenn es gefunden wird (wie im obigen Beispiel), wird es heruntergeladen und im Zertifikatspeicher installiert. Wenn Ihr Computer nicht mit dem Internet verbunden ist, extrahiert CCE den Zertifikatsinhalt aus der Bibliothek crypt32.dll und installiert das Zertifikat im Container "Vertrauenswürdige Stammzertifizierungsstellen".