Zertifizierungsstellen und Vertrauensketten

Asymmetrische Verschlüsselung ist nur dann nützlich, wenn Sie darauf vertrauen können, dass ein öffentlicher Schlüssel tatsächlich der Person oder Organisation gehört, der Sie ihn zuordnen. Ohne einen Vertrauensmechanismus kann ein Angreifer Ihre Anfrage nach dem öffentlichen Schlüssel einer Person abfangen und seinen eigenen unterschieben – ein klassischer Man-in-the-Middle-Angriff. Die Public-Key-Infrastruktur (PKI) löst dieses Vertrauensproblem durch eine Zertifizierungsstelle (CA) – eine vertrauenswürdige dritte Partei, die Zertifikate digital signiert und damit öffentliche Schlüssel an überprüfte Identitäten bindet. Wenn Sie der CA vertrauen, können Sie allen Personen und Organisationen vertrauen, die von der CA zertifiziert wurden.

Eine Zertifizierungsstelle (CA) ist eine Organisation, die digitale Zertifikate ausstellt, nachdem sie die Identität des Antragstellers überprüft hat. Die CA signiert jedes Zertifikat mit ihrem eigenen privaten Schlüssel. Dadurch kann jeder, der der CA vertraut, die Echtheit des Zertifikats mithilfe des öffentlichen Schlüssels der CA überprüfen. Es gibt zwei Typen: öffentliche CAs (wie DigiCert, GlobalSign und Let's Encrypt), deren Root-Zertifikate in Betriebssystemen und Browsern vorinstalliert sind, sowie private (interne) CAs, die Organisationen selbst für die interne Ausstellung von Zertifikaten betreiben (VPNs, interne Dienste und Gerätezertifikate).

Eine Root-CA ist die oberste Instanz in einer PKI-Hierarchie. Root-CA-Zertifikate sind selbstsigniert – es gibt keine übergeordnete Instanz, die sie validieren könnte. Stattdessen wird Root-Zertifikaten vertraut, weil Anbieter von Betriebssystemen (Microsoft, Apple, Mozilla) Root-CAs durch gründliche Auditprozesse überprüfen und ihre Zertifikate vorab in vertrauenswürdigen Zertifikatsspeichern installieren. In einem typischen Trust Store eines Browsers befinden sich etwa 130–150 vertrauenswürdige Root-CAs. Wird eine Root-CA kompromittiert, sind alle von ihr jemals ausgestellten Zertifikate verdächtig. Deshalb werden die privaten Schlüssel von Root-CAs in Offline-Hardware-Sicherheitsmodulen (HSMs) gespeichert, die physisch von Netzwerken getrennt sind.

Root-CAs stellen Endentitäten nur selten direkt Zertifikate aus. Stattdessen erstellen sie Intermediate-CAs (auch Subordinate CAs genannt), indem sie Zertifikate an Betreiber von Intermediate-CAs ausstellen. Intermediate-CAs stellen anschließend Zertifikate für Endentitäten aus (etwa HTTPS-Serverzertifikate). Diese Delegationshierarchie erfüllt mehrere Zwecke: Sie schützt die privaten Schlüssel der Root-CA, indem diese offline bleiben (wird eine Intermediate-CA kompromittiert, wird nur ihre Zertifikatskette widerrufen, nicht die gesamte Root-CA); sie ermöglicht spezialisierte CAs für unterschiedliche Anwendungsfälle (Codesignierung im Vergleich zu TLS); und sie unterstützt eine Organisationshierarchie innerhalb einer privaten PKI.

Eine Zertifikatskette (oder Vertrauenskette) ist die Abfolge von Zertifikaten, die vom Zertifikat der Endentität bis zurück zur vertrauenswürdigen Root-CA reicht. Für eine typische HTTPS-Website lautet die Kette: Zertifikat der Endentität (z. B. *.google.com) → Zertifikat der Intermediate-CA (z. B. Google Trust Services WR2) → Zertifikat der Root-CA (z. B. Google Trust Services LLC). Wenn Ihr Browser eine Website aufruft, validiert er die gesamte Kette. Dabei überprüft er, ob die Signatur jedes Zertifikats von der jeweils übergeordneten Ebene stammt und ob die Root-CA im vertrauenswürdigen Speicher enthalten ist. Jede Unterbrechung dieser Kette führt zu einem Zertifikatsfehler.

Wenn zwei getrennte PKI-Hierarchien gegenseitiges Vertrauen herstellen müssen, verwenden sie eine Cross-Zertifizierung. Jede CA stellt der Root-CA der jeweils anderen ein Zertifikat aus und etabliert dadurch Vertrauen in beide Richtungen. Eine Bridge-CA ist eine zentrale CA, die Cross-Zertifizierungen mit mehreren Bereichs-CAs durchführt und so ein Vertrauensnetz zwischen verschiedenen Organisationen oder Behörden schafft. Die US Federal Bridge CA verbindet mehrere PKI-Systeme der US-Bundesregierung. Cross-Zertifizierung ist komplex zu verwalten, aber notwendig, wenn Organisationen zusammengeführt werden oder Vertrauen zwischen Behörden hergestellt werden soll, ohne alles in eine einzige Hierarchie zu überführen.

Eine Registrierungsstelle (RA) ist eine Instanz, die im Auftrag einer CA die Identität überprüft, selbst aber keine Zertifikate ausstellt. Die RA nimmt Zertifikatsanträge entgegen, überprüft die Identität des Antragstellers (je nach Zertifikatstyp durch Dokumentenprüfung, Domainvalidierung oder persönliche Identitätsprüfung) und leitet genehmigte Anträge zur Signierung an die CA weiter. Durch diese Delegation können CAs ihre Ausstellungskapazität erhöhen, ohne sämtliche Überprüfungen selbst durchführen zu müssen. In einer Unternehmens-PKI kann die RA beispielsweise die Personalabteilung oder der IT-Helpdesk sein, die bzw. der Zertifikatsanträge von Mitarbeitenden validiert.

CAs bieten Zertifikate mit unterschiedlichen Validierungsstufen an, die widerspiegeln, wie gründlich die Identität des Antragstellers überprüft wurde. Domain Validation (DV): Die CA überprüft lediglich, ob der Antragsteller die Kontrolle über die Domain besitzt (automatisiert, dauert wenige Minuten, wird von Let's Encrypt verwendet). Organization Validation (OV): Die CA überprüft die rechtliche Existenz der Organisation (1–3 Werktage). Extended Validation (EV): die gründlichste Prüfung – rechtliche Identität, physische Adresse und operative Existenz (1–2 Wochen; wurde verwendet, um den grünen Unternehmensnamen in der Adressleiste des Browsers anzuzeigen). DV ist für grundlegende Verschlüsselung ausreichend; EV eignet sich für besonders schützenswerte Ziele wie Banking-Websites.

Certificate Pinning ist ein Verfahren, bei dem eine Anwendung so programmiert wird, dass sie nur einem bestimmten Zertifikat oder einer bestimmten CA vertraut, statt jedem Zertifikat einer beliebigen vertrauenswürdigen Root-CA. Dadurch werden MITM-Angriffe verhindert, selbst wenn ein Angreifer ein betrügerisches Zertifikat von einer vertrauenswürdigen CA erhält. Mobile Apps und sicherheitskritische Anwendungen verwenden Pinning, um sicherzustellen, dass sie nur die Zertifikate ihrer eigenen Server akzeptieren. Der Nachteil: Läuft das festgelegte Zertifikat ab oder wird es ausgetauscht, funktioniert die Anwendung nicht mehr, bis die App aktualisiert wurde. HPKP (HTTP Public Key Pinning) war ein browserbasiertes Pinning-Verfahren, das aufgrund des Risikos fehlerhafter Bereitstellungen eingestellt wurde.

Organisationen betreiben für interne Zertifikatsanforderungen eine eigene private CA – zur Authentifizierung von VPN-Clients, Ausstellung von Zertifikaten für interne HTTPS-Dienste, Signierung von Code und Authentifizierung von Geräten. Active Directory Certificate Services (AD CS) von Microsoft ist die in Unternehmen am häufigsten verwendete private CA. Zertifikate einer internen CA müssen an alle Geräte und Browser verteilt werden, die intern ausgestellten Zertifikaten vertrauen müssen, typischerweise über Gruppenrichtlinien. Private CAs können keine Zertifikate ausstellen, denen das öffentliche Internet vertraut. Ihre Verwendung ist auf die Geräte der Organisation beschränkt, auf denen die Root-CA der privaten PKI installiert ist.

Die Kompromittierung von DigiNotar (2011) ist der wichtigste CA-Vorfall, den Kandidaten für Security+ kennen sollten. Die niederländische CA DigiNotar wurde von Angreifern kompromittiert, die betrügerische Zertifikate für Google, Mozilla und Regierungsdomains ausstellten. Diese wurden im Iran verwendet, um Man-in-the-Middle-Angriffe auf Bürgerinnen und Bürger durchzuführen. Daraufhin entfernten alle großen Browser- und Betriebssystemanbieter DigiNotar umgehend aus ihren vertrauenswürdigen Root-Speichern und erklärten damit alle von DigiNotar jemals ausgestellten Zertifikate für ungültig. DigiNotar ging innerhalb weniger Wochen bankrott. Dieser Vorfall zeigte, dass die Kompromittierung einer CA katastrophale Folgen hat und warum CAA-DNS-Einträge, Certificate Transparency und Multi-Faktor-Authentifizierung für CA-Systeme inzwischen erforderlich sind.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Zertifizierungsstellen binden öffentliche Schlüssel an verifizierte Identitäten; die Vertrauenskette verläuft von der Endentität über Zwischen-CAs bis zu einer selbstsignierten Root-CA; Root-CAs werden offline in HSMs aufbewahrt und von Betriebssystemen vorab als vertrauenswürdig eingestuft; und eine Kompromittierung einer CA (DigiNotar) kann Millionen von Zertifikaten ungültig machen. Als Nächstes sehen wir uns die Struktur von X.509-Zertifikaten an.