X.509

Aus besserwiki.de
X.509 ⓘ
Informationstechnologie - Open Systems Interconnection - Das Verzeichnis: Rahmenwerk für Public-Key- und Attribut-Zertifikate
StatusIn Kraft (Empfehlung)
Erstmals veröffentlicht1,0 am November 25, 1988; vor 34 Jahren
Letzte Version9.1
Oktober 14, 2021; vor 16 Monaten
OrganisationITU-T
AusschussITU-T Studiengruppe 17
ReiheX
Grundlegende NormenASN.1
Verwandte NormenISO/IEC 9594-8:2020, X.500
BereichKryptographie
Websitewww.itu.int/rec/T-REC-X.509

In der Kryptografie ist X.509 ein Standard der Internationalen Fernmeldeunion (ITU), der das Format von Zertifikaten für öffentliche Schlüssel definiert. X.509-Zertifikate werden in vielen Internetprotokollen verwendet, darunter TLS/SSL, das die Grundlage für HTTPS, das sichere Protokoll zum Surfen im Internet, bildet. Sie werden auch in Offline-Anwendungen wie elektronischen Signaturen verwendet. ⓘ

Ein X.509-Zertifikat verknüpft eine Identität mit einem öffentlichen Schlüssel unter Verwendung einer digitalen Signatur. Ein Zertifikat enthält eine Identität (einen Hostnamen, eine Organisation oder eine Person) und einen öffentlichen Schlüssel (RSA, DSA, ECDSA, ed25519 usw.) und wird entweder von einer Zertifizierungsstelle signiert oder ist selbst signiert. Wenn ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle signiert oder auf andere Weise validiert wurde, kann jemand, der dieses Zertifikat besitzt, den darin enthaltenen öffentlichen Schlüssel verwenden, um eine sichere Kommunikation mit einer anderen Partei aufzubauen oder Dokumente zu validieren, die mit dem entsprechenden privaten Schlüssel digital signiert wurden. ⓘ

X.509 definiert auch Zertifikatswiderrufslisten, die ein Mittel sind, um Informationen über Zertifikate zu verbreiten, die von einer signierenden Behörde als ungültig eingestuft wurden, sowie einen Algorithmus zur Validierung des Zertifizierungspfads, der es ermöglicht, dass Zertifikate von zwischengeschalteten CA-Zertifikaten signiert werden, die wiederum von anderen Zertifikaten signiert werden und schließlich einen Vertrauensanker erreichen. ⓘ

X.509 wurde vom "Standardization Sector" der Internationalen Fernmeldeunion (ITU-T) in der ITU-T Study Group 17 definiert und basiert auf ASN.1, einem weiteren ITU-T-Standard. ⓘ

X.509 ist ein ITU-T-Standard für eine Public-Key-Infrastruktur zum Erstellen digitaler Zertifikate. Der Standard ist auch als ISO/IEC 9594-8 zuletzt im November 2020 aktualisiert worden. Der Standard spezifiziert die folgenden Datentypen: Public-Key-Zertifikat, Attributzertifikat, Certificate Revocation List (CRL) und Attribute Certificate Revocation List (ACRL). In der elektronischen Kommunikation finden X.509-Zertifikate Anwendung bei den TLS-Versionen diverser Übertragungsprotokolle, wie z. B. beim Abruf von Web-Seiten mit HTTPS oder zum Unterschreiben und Verschlüsseln von E-Mails nach dem S/MIME-Standard. ⓘ

Geschichte und Verwendung

X.509 wurde erstmals am 3. Juli 1988 veröffentlicht und wurde in Verbindung mit dem X.500-Standard eingeführt. Seine erste Aufgabe war es, den Benutzern einen sicheren Zugang zu Informationsressourcen zu ermöglichen und einen kryptografischen Man-in-the-Middle-Angriff zu verhindern. Es geht von einem streng hierarchischen System von Zertifizierungsstellen (CAs) für die Ausstellung der Zertifikate aus. Dies steht im Gegensatz zu Web-of-Trust-Modellen wie PGP, bei denen jeder (nicht nur spezielle Zertifizierungsstellen) die Schlüsselzertifikate anderer signieren und damit deren Gültigkeit bescheinigen kann. ⓘ

Version 3 von X.509 bietet die Flexibilität, andere Topologien wie Bridges und Meshes zu unterstützen. Es kann in einem Peer-to-Peer, OpenPGP-ähnlichen Netz des Vertrauens verwendet werden, wurde aber bis 2004 nur selten auf diese Weise genutzt. Das X.500-System wurde nur von souveränen Nationen zum Zwecke der Erfüllung von Verträgen über den Austausch von Identitätsdaten implementiert, und die Arbeitsgruppe Public-Key Infrastructure (X.509) (PKIX) der IETF hat den Standard an die flexiblere Organisation des Internets angepasst. Der Begriff X.509-Zertifikat bezieht sich in der Regel auf das PKIX-Zertifikat und das CRL-Profil des X.509 v3-Zertifikatstandards der IETF, wie in RFC 5280 beschrieben, das allgemein als PKIX für Public Key Infrastructure (X.509) bezeichnet wird. ⓘ

Ein frühes Problem mit Public Key Infrastructure (PKI) und X.509-Zertifikaten war das bekannte "welches Verzeichnis"-Problem. Das Problem besteht darin, dass der Client nicht weiß, wo er fehlende Zwischenzertifikate abrufen kann, weil das globale X.500-Verzeichnis nie existiert hat. Das Problem wurde dadurch entschärft, dass alle Zwischenzertifikate in eine Anfrage aufgenommen wurden. Frühe Webserver schickten zum Beispiel nur das Zertifikat des Webservers an den Client. Clients, die kein Zwischenzertifikat der Zertifizierungsstelle hatten oder nicht wussten, wo sie zu finden waren, konnten keinen gültigen Pfad von der Zertifizierungsstelle zum Zertifikat des Servers erstellen. Um das Problem zu umgehen, senden Webserver jetzt alle Zwischenzertifikate zusammen mit dem Zertifikat des Webservers. ⓘ

PKIX bezieht sich zwar auf den PKI-Standard der IETF oder des Internets, es gibt jedoch viele andere PKIs mit anderen Richtlinien. Die US-Regierung hat zum Beispiel ihre eigene PKI mit eigenen Richtlinien, und das CA/Browser Forum hat seine eigene PKI mit eigenen Richtlinien. Die PKI der US-Regierung ist ein umfangreiches Buch mit über 2500 Seiten. Wenn die PKI einer Organisation zu sehr von der der IETF oder des CA/Browser Forums abweicht, besteht die Gefahr, dass die Organisation die Interoperabilität mit gängigen Tools wie Webbrowsern, cURL und Wget verliert. Wenn eine PKI beispielsweise die Richtlinie hat, dass Zertifikate nur am Montag ausgestellt werden dürfen, dann werden gängige Tools wie cURL und Wget diese Richtlinie nicht durchsetzen und ein am Dienstag ausgestelltes Zertifikat zulassen. ⓘ

Zertifikate

X.509-Zertifikate verbinden eine Identität mit einem öffentlichen Schlüssel unter Verwendung einer digitalen Signatur. Im X.509-System gibt es zwei Arten von Zertifikaten. Das erste ist ein CA-Zertifikat. Das zweite ist ein End-Entity-Zertifikat. Ein CA-Zertifikat kann andere Zertifikate ausstellen. Das oberste, selbstsignierte CA-Zertifikat wird manchmal als Root-CA-Zertifikat bezeichnet. Andere CA-Zertifikate werden als Zwischenzertifikate oder untergeordnete CA-Zertifikate bezeichnet. Ein Endteilnehmer-Zertifikat identifiziert den Benutzer, z. B. eine Person, eine Organisation oder ein Unternehmen. Ein Endteilnehmer-Zertifikat kann keine anderen Zertifikate ausstellen. Ein End-Entity-Zertifikat wird manchmal auch als Blattzertifikat bezeichnet, da unter ihm keine weiteren Zertifikate ausgestellt werden können. ⓘ

Eine Organisation, die ein signiertes Zertifikat wünscht, fordert dieses bei einer CA über ein Protokoll wie Certificate Signing Request (CSR), Simple Certificate Enrollment Protocol (SCEP) oder Certificate Management Protocol (CMP) an. Die Organisation generiert zunächst ein Schlüsselpaar, wobei sie den privaten Schlüssel geheim hält und ihn zum Signieren der CSR verwendet. Der CSR enthält Informationen zur Identifizierung des Antragstellers und den öffentlichen Schlüssel des Antragstellers, der zur Überprüfung der Signatur des CSR verwendet wird, sowie den Distinguished Name (DN), der für die Person, Organisation oder das Unternehmen eindeutig ist. Der CSR kann von anderen, von der Zertifizierungsstelle geforderten Referenzen oder Identitätsnachweisen begleitet werden. ⓘ

Der CSR wird von einer Registrierungsstelle (Registration Authority, RA) validiert, und anschließend stellt die Zertifizierungsstelle ein Zertifikat aus, das einen öffentlichen Schlüssel an einen bestimmten Distinguished Name bindet. Die Rollen Registrierungsstelle und Zertifizierungsstelle sind in der Regel getrennte Geschäftseinheiten mit getrennten Aufgaben, um das Risiko von Betrug zu verringern. ⓘ

Die vertrauenswürdigen Stammzertifikate einer Organisation können an alle Mitarbeiter verteilt werden, damit sie das PKI-System des Unternehmens nutzen können. Bei Browsern wie Internet Explorer, Firefox, Opera, Safari und Chrome ist eine Reihe von Stammzertifikaten vorinstalliert, so dass SSL-Zertifikate der großen Zertifizierungsstellen sofort funktionieren; die Entwickler der Browser legen fest, welche Zertifizierungsstellen für die Benutzer der Browser vertrauenswürdige Dritte sind. Firefox bietet zum Beispiel eine CSV- und/oder HTML-Datei mit einer Liste der einbezogenen Zertifizierungsstellen. ⓘ

X.509 und RFC 5280 enthalten auch Standards für die Implementierung von Zertifikatswiderrufslisten (CRL). Eine weitere, von der IETF genehmigte Methode zur Überprüfung der Gültigkeit eines Zertifikats ist das Online Certificate Status Protocol (OCSP). In Firefox 3.0 ist die OCSP-Prüfung standardmäßig aktiviert, ebenso wie in den Windows-Versionen ab Vista und später. ⓘ

Aufbau eines Zertifikats

Die von den Standards vorgesehene Struktur wird in einer formalen Sprache, der Abstract Syntax Notation One (ASN.1), ausgedrückt. ⓘ

Die Struktur eines digitalen X.509 v3-Zertifikats ist wie folgt:

  • Zertifikat
    • Versionsnummer
    • Seriennummer
    • Signatur-Algorithmus-ID
    • Name des Ausstellers
    • Gültigkeitsdauer
      • Nicht vor
      • Nicht danach
    • Name des Subjekts
    • Information über den öffentlichen Schlüssel des Subjekts
      • Algorithmus des öffentlichen Schlüssels
      • Öffentlicher Schlüssel des Subjekts
    • Eindeutige Kennung des Ausstellers (optional)
    • Eindeutiger Identifikator des Subjekts (optional)
    • Erweiterungen (optional)
      • ...
  • Zertifikat-Signatur-Algorithmus
  • Zertifikatssignatur ⓘ

Jede Erweiterung hat ihre eigene eindeutige ID, ausgedrückt als Objektidentifikator (OID), der aus einer Reihe von Werten besteht, zusammen mit einer kritischen oder nicht-kritischen Angabe. Ein System, das ein Zertifikat verwendet, muss das Zertifikat zurückweisen, wenn es auf eine kritische Erweiterung stößt, die es nicht erkennt, oder eine kritische Erweiterung, die Informationen enthält, die es nicht verarbeiten kann. Eine nicht kritische Erweiterung kann ignoriert werden, wenn sie nicht erkannt wird, muss aber verarbeitet werden, wenn sie erkannt wird. ⓘ

Die Struktur von Version 1 ist in RFC 1422 beschrieben. ⓘ

Die ITU-T hat in Version 2 eindeutige Identifikatoren für Ausgeber und Subjekte eingeführt, um die Wiederverwendung von Ausgeber- oder Subjektnamen nach einiger Zeit zu ermöglichen. Ein Beispiel für die Wiederverwendung ist, wenn eine CA in Konkurs geht und ihr Name aus der öffentlichen Liste des Landes gelöscht wird. Nach einiger Zeit kann sich eine andere CA mit demselben Namen registrieren, auch wenn sie mit der ersten nicht verwandt ist. Die IETF empfiehlt jedoch, dass keine Namen von Ausstellern und Subjekten wiederverwendet werden. Daher ist die Version 2 im Internet nicht weit verbreitet. ⓘ

Erweiterungen wurden in Version 3 eingeführt. Eine Zertifizierungsstelle kann Erweiterungen verwenden, um ein Zertifikat nur für einen bestimmten Zweck auszustellen (z. B. nur zum Signieren von digitalen Objekten). ⓘ

In allen Versionen muss die Seriennummer für jedes von einer bestimmten CA ausgestellte Zertifikat eindeutig sein (wie in RFC 5280 erwähnt). ⓘ

Erweiterungen, die über eine bestimmte Verwendung eines Zertifikats informieren

RFC 5280 (und seine Vorgänger) definiert eine Reihe von Zertifikatserweiterungen, die angeben, wie das Zertifikat verwendet werden soll. Die meisten von ihnen sind Bögen aus der joint-iso-ccitt(2) ds(5) id-ce(29) OID. Einige der gebräuchlichsten, die in Abschnitt 4.2.1 definiert sind, sind:

  • Basic Constraints, { id-ce 19 }, werden verwendet, um anzuzeigen, ob das Zertifikat ein CA-Zertifikat ist und andere Zertifikate zertifizieren oder ausstellen kann. Eine Einschränkung kann als kritisch gekennzeichnet werden. Wenn eine Einschränkung als kritisch markiert ist, muss ein Agent das Zertifikat nicht verarbeiten, wenn er die Einschränkung nicht versteht. Ein Agent kann eine nicht kritische Bedingung, die er nicht versteht, weiter verarbeiten.
  • Key Usage, { id-ce 15 }, liefert eine Bitmap, die angibt, welche kryptografischen Operationen mit dem im Zertifikat enthaltenen öffentlichen Schlüssel durchgeführt werden dürfen; sie könnte z. B. angeben, dass der Schlüssel für Signaturen, nicht aber für Verschlüsselungen verwendet werden soll.
  • Extended Key Usage, { id-ce 37 }, wird typischerweise in einem Blattzertifikat verwendet, um den Zweck des im Zertifikat enthaltenen öffentlichen Schlüssels anzugeben. Sie enthält eine Liste von OIDs, von denen jede eine zulässige Verwendung angibt. Zum Beispiel zeigt { id-pkix 3 1 } an, dass der Schlüssel auf der Serverseite einer TLS- oder SSL-Verbindung verwendet werden kann; { id-pkix 3 4 } zeigt an, dass der Schlüssel zur Sicherung von E-Mails verwendet werden kann. ⓘ

Wenn ein Zertifikat mehrere Erweiterungen hat, die seine Verwendung einschränken, müssen im Allgemeinen bei der Verwendung von RFC 5280 alle Einschränkungen erfüllt sein, damit eine bestimmte Verwendung angemessen ist. Der RFC nennt das konkrete Beispiel eines Zertifikats, das sowohl keyUsage als auch extendedKeyUsage enthält: In diesem Fall müssen beide verarbeitet werden, und das Zertifikat kann nur verwendet werden, wenn beide Erweiterungen bei der Spezifikation der Verwendung eines Zertifikats kohärent sind. NSS beispielsweise verwendet beide Erweiterungen zur Angabe der Zertifikatsverwendung. ⓘ

Erweiterte Validierungszertifikate

Zertifizierungsstellen, die im Rahmen der PKI des CA/Browser-Forums tätig sind, stellen Zertifikate mit unterschiedlichen Validierungsstufen aus. Die verschiedenen Validierungen bieten unterschiedliche Sicherheiten, dass ein Zertifikat das repräsentiert, was es repräsentieren soll. Zum Beispiel kann ein Webserver auf der niedrigsten Stufe der Sicherheit mit einer E-Mail namens Domain Validation (DV) validiert werden. Oder ein Webserver kann auf einer höheren Sicherheitsebene mit detaillierteren Methoden, der so genannten Extended Validation (EV), validiert werden. ⓘ

In der Praxis bedeutet ein DV-Zertifikat, dass ein Zertifikat für eine Domain wie example.com ausgestellt wurde, nachdem jemand auf eine an webmaster@example.com gesendete E-Mail geantwortet hat. Ein EV-Zertifikat bedeutet, dass ein Zertifikat für eine Domäne wie example.com ausgestellt wurde und ein Unternehmen wie Example, LLC der Eigentümer der Domäne ist und der Eigentümer durch die Gründungsurkunde verifiziert wurde. ⓘ

Die erweiterte Validierung fügt keine zusätzlichen Sicherheitskontrollen hinzu, so dass die Einrichtung eines sicheren Kanals mit einem EV-Zertifikat nicht "stärker" ist als die Einrichtung eines Kanals mit einer anderen Validierungsstufe wie DV. ⓘ

Die erweiterte Validierung wird in einem Zertifikat mit der X.509 v3-Erweiterung signalisiert. Jede CA verwendet einen anderen Object Identifier (OID), um die erweiterte Validierung zu bestätigen. Es gibt keine einheitliche OID für die Anzeige der erweiterten Validierung, was die Programmierung der Benutzeragenten erschwert. Jeder User-Agent muss über eine Liste von OIDs verfügen, die eine erweiterte Validierung anzeigen. ⓘ

Die PKI des CA/Browser-Forums erkennt die erweiterte Validierung an, und viele Browser geben dem Benutzer ein visuelles Feedback, um anzuzeigen, dass eine Website ein EV-Zertifikat bereitstellt. Andere PKIs, wie die Internet-PKI (PKIX), legen keinen besonderen Wert auf eine erweiterte Validierung. Tools, die PKIX-Richtlinien verwenden, wie cURL und Wget, behandeln ein EV-Zertifikat einfach wie jedes andere Zertifikat. ⓘ

Der Sicherheitsexperte Peter Gutmann erklärt, dass die Zertifizierungsstellen EV-Zertifikate eingeführt haben, um ihre Gewinne wiederherzustellen, nachdem das "Race to the Bottom" die Gewinne geschmälert hatte. Während des "Race to the Bottom" senkten die Zertifizierungsstellen die Preise, um Verbraucher zum Kauf ihrer Zertifikate zu bewegen. Infolgedessen sanken die Gewinne, und die Zertifizierungsstellen verringerten das Niveau der von ihnen durchgeführten Validierung bis zu dem Punkt, an dem es fast keine Garantien mehr für ein Zertifikat gab. ⓘ

Dateinamenerweiterungen für Zertifikate

Es gibt mehrere häufig verwendete Dateinamenerweiterungen für X.509-Zertifikate. Leider werden einige dieser Erweiterungen auch für andere Daten wie private Schlüssel verwendet. ⓘ

  • .pem - (Privacy-enhanced Electronic Mail) Base64-kodiertes DER-Zertifikat, eingeschlossen zwischen -----BEGIN ZERTIFIKAT----- und -----END CERTIFICATE-----
  • .cer, .crt, .der - normalerweise in binärer DER-Form, aber auch Base64-kodierte Zertifikate sind üblich (siehe .pem oben)
  • .p7b, .p7c - PKCS#7 SignedData-Struktur ohne Daten, nur Zertifikat(e) oder CRL(s)
  • .p12 - PKCS#12, kann Zertifikat(e) (öffentlich) und private Schlüssel (passwortgeschützt) enthalten
  • .pfx - PFX, Vorgänger von PKCS#12 (enthält in der Regel Daten im PKCS#12-Format, z. B. bei PFX-Dateien, die im IIS erzeugt werden) ⓘ

PKCS#7 ist ein Standard zum Signieren oder Verschlüsseln (offiziell "Enveloping" genannt) von Daten. Da das Zertifikat benötigt wird, um signierte Daten zu verifizieren, ist es möglich, sie in die SignedData-Struktur aufzunehmen. Eine .P7C-Datei ist eine degenerierte SignedData-Struktur, die keine zu signierenden Daten enthält. ⓘ

PKCS#12 hat sich aus dem PFX-Standard (Personal Information Exchange) entwickelt und wird für den Austausch öffentlicher und privater Objekte in einer einzigen Datei verwendet. ⓘ

Eine .PEM-Datei kann Zertifikate und/oder private Schlüssel enthalten, die von entsprechenden BEGIN/END-Zeilen umschlossen sind. ⓘ

Zertifikatsketten und Cross-Zertifizierung

Eine Zertifikatskette (siehe das äquivalente Konzept des "Zertifizierungspfads", definiert in RFC 5280, Abschnitt 3.2) ist eine Liste von Zertifikaten (in der Regel beginnend mit einem Endteilnehmer-Zertifikat), gefolgt von einem oder mehreren CA-Zertifikaten (das letzte ist in der Regel ein selbstsigniertes Zertifikat), mit den folgenden Eigenschaften:

  1. Der Aussteller jedes Zertifikats (mit Ausnahme des letzten) stimmt mit dem Betreff des nächsten Zertifikats in der Liste überein.
  2. Jedes Zertifikat (mit Ausnahme des letzten) ist mit dem geheimen Schlüssel des nächsten Zertifikats in der Kette signiert (d.h. die Signatur eines Zertifikats kann mit dem öffentlichen Schlüssel des folgenden Zertifikats überprüft werden)
  3. Das letzte Zertifikat in der Liste ist ein Vertrauensanker: ein Zertifikat, dem Sie vertrauen, weil es Ihnen durch ein vertrauenswürdiges Verfahren zugestellt wurde ⓘ

Zertifikatsketten werden verwendet, um zu überprüfen, ob der in einem Zielzertifikat (dem ersten Zertifikat in der Kette) enthaltene öffentliche Schlüssel (PK) und andere darin enthaltene Daten tatsächlich zu seinem Subjekt gehören. Um dies festzustellen, wird die Signatur des Zielzertifikats mit dem PK des folgenden Zertifikats überprüft, dessen Signatur mit dem nächsten Zertifikat überprüft wird, und so weiter, bis das letzte Zertifikat in der Kette erreicht ist. Da das letzte Zertifikat ein Vertrauensanker ist, beweist das erfolgreiche Erreichen dieses Zertifikats, dass dem Zielzertifikat vertraut werden kann. ⓘ

Die Beschreibung im vorangegangenen Absatz ist eine vereinfachte Darstellung des Prozesses zur Validierung des Zertifizierungspfads, wie er in RFC 5280 Abschnitt 6 definiert ist, der zusätzliche Prüfungen umfasst, wie die Überprüfung des Gültigkeitsdatums von Zertifikaten, das Nachschlagen in CRLs usw. ⓘ

Beispiel 1: Kreuzzertifizierung zwischen zwei PKI ⓘ
Beispiel 2: Erneuerung von CA-Zertifikaten ⓘ

Bei der Untersuchung, wie Zertifikatsketten aufgebaut und validiert werden, ist es wichtig zu beachten, dass ein konkretes Zertifikat Teil sehr unterschiedlicher Zertifikatsketten sein kann (die alle gültig sind). Dies liegt daran, dass mehrere CA-Zertifikate für denselben Betreff und denselben öffentlichen Schlüssel generiert werden können, aber mit verschiedenen privaten Schlüsseln (von verschiedenen CAs oder verschiedenen privaten Schlüsseln derselben CA) signiert sein können. Obwohl also ein einzelnes X.509-Zertifikat nur einen Aussteller und eine CA-Signatur haben kann, kann es gültig mit mehr als einem Zertifikat verknüpft werden, wodurch völlig unterschiedliche Zertifikatsketten entstehen. Dies ist entscheidend für die Cross-Zertifizierung zwischen PKIs und anderen Anwendungen. Siehe die folgenden Beispiele: ⓘ

Beispiele

In diesen Diagrammen:

  • Jedes Kästchen steht für ein Zertifikat, der Betreff ist fett gedruckt
  • A → B bedeutet "A ist von B signiert" (oder genauer: "A ist von dem geheimen Schlüssel signiert, der dem in B enthaltenen öffentlichen Schlüssel entspricht").
  • Zertifikate mit der gleichen Farbe (die nicht weiß/transparent sind) enthalten den gleichen öffentlichen Schlüssel ⓘ

Beispiel 1: Kreuzzertifizierung auf Ebene der Stammzertifizierungsstelle (CA) zwischen zwei PKI

Um zu erreichen, dass Benutzerzertifikate, die in PKI 2 existieren (wie "Benutzer 2"), von PKI 1 als vertrauenswürdig eingestuft werden, erzeugt CA1 ein Zertifikat (cert2.1), das den öffentlichen Schlüssel von CA2 enthält. Nun haben sowohl "cert2 als auch cert2.1 (in grün) denselben Betreff und öffentlichen Schlüssel, so dass es zwei gültige Ketten für cert2.2 (Benutzer 2) gibt: "cert2.2 → cert2" und "cert2.2 → cert2.1 → cert1". ⓘ

In ähnlicher Weise kann CA2 ein Zertifikat (cert1.1) erzeugen, das den öffentlichen Schlüssel von CA1 enthält, so dass in PKI 1 vorhandene Benutzerzertifikate (wie "Benutzer 1") von PKI 2 als vertrauenswürdig eingestuft werden. ⓘ

Beispiel 2: Erneuerung von CA-Zertifikaten

Verständnis der Konstruktion von Zertifizierungspfaden (PDF). PKI Forum. September 2002. Um einen reibungslosen Übergang vom alten Signierschlüsselpaar zum neuen Signierschlüsselpaar zu ermöglichen, sollte die CA ein Zertifikat ausstellen, das den alten öffentlichen Schlüssel enthält, der durch den neuen privaten Signierschlüssel signiert ist, und ein Zertifikat, das den neuen öffentlichen Schlüssel enthält, der durch den alten privaten Signierschlüssel signiert ist. Diese beiden Zertifikate sind selbst ausgestellt, aber keines ist selbst signiert. Beachten Sie, dass diese zusätzlich zu den beiden selbstsignierten Zertifikaten (ein altes und ein neues) ausgestellt werden. ⓘ

Da sowohl cert1 als auch cert3 denselben öffentlichen Schlüssel (den alten) enthalten, gibt es zwei gültige Zertifikatsketten für cert5: "cert5 → cert1" und "cert5 → cert3 → cert2", und analog für cert6. Dadurch können alte Benutzerzertifikate (z. B. cert5) und neue Zertifikate (z. B. cert6) von einer Partei, die während des Übergangs zu den neuen CA-Schlüsseln entweder das neue Root-CA-Zertifikat oder das alte als Vertrauensanker hat, als vertrauenswürdig angesehen werden. ⓘ

Beispiel für X.509-Zertifikate

Dies ist ein Beispiel für ein entschlüsseltes X.509-Zertifikat, das von wikipedia.org und mehreren anderen Wikipedia-Websites verwendet wurde. Es wurde von GlobalSign ausgestellt, wie im Feld Issuer angegeben. Das Feld Subject beschreibt Wikipedia als Organisation, und das Feld Subject Alternative Name (SAN) für DNS beschreibt die Hostnamen, für die es verwendet werden kann. Das Feld Subject Public Key Info enthält einen öffentlichen ECDSA-Schlüssel, während die Signatur am unteren Rand mit dem privaten RSA-Schlüssel von GlobalSign erzeugt wurde. ⓘ

Endteilnehmer-Zertifikat

Zertifikat: 

    Daten:
        Version: 3 (0x2)
        Seriennummer:
            03:04:54:08:f9:ff:10:92:e1:69:fe:49:8f:78:d3:6d:dc:47
        Unterschriftsalgorithmus: sha256WithRSAEncryption
        Aussteller: C = US, O = Let's Encrypt, CN = R3
        Gültigkeit
            Nicht vor: Jul 15 08:01:49 2021 GMT
            Nicht nach: Oct 13 08:01:48 2021 GMT
        Betreff: CN = *.wikipedia.org
        Betreff Public Key Info:
            Öffentlicher Schlüssel Algorithmus: id-ecPublicKey
                Öffentlicher-Schlüssel: (256 bit)
                pub:
                    04:a5:9a:47:b2:d3:fc:a7:df:de:f6:cb:45:62:0a:
                    d3:c1:a7:38:de:20:bd:d7:10:7d:58:73:de:8d:a1:
                    99:70:0c:dd:ab:91:3f:0e:83:97:1b:4f:a2:99:f3:
                    f8:30:73:ef:da:be:91:25:18:7a:d6:da:bf:e5:e9:
                    72:a3:41:31:7a
                ASN1 OID: prime256v1
                NIST-KURVE: P-256
        X509v3 Erweiterungen:
            X509v3 Schlüsselverwendung: kritisch
                Digitale Signatur
            X509v3 Erweiterte Schlüsselverwendung:
                TLS Web Server Authentifizierung, TLS Web Client Authentifizierung
            X509v3 Basic Constraints: kritisch
                CA:FALSE
            X509v3 Subject Key Kennung:
                08:0E:29:26:07:E9:B4:5B:63:2D:86:5D:F6:E2:5A:8C:CD:6A:D0:A7
            X509v3 Autoritätsschlüssel-Bezeichner:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6 ⓘ

            Zugriff auf Autoritätsinformationen:
                OCSP - URI:http://r3.o.lencr.org</nowiki>
                CA-Aussteller - URI:http://r3.i.lencr.org/</nowiki> ⓘ

            X509v3 Betreff Alternativer Name:
                DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*. m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*. wikipedia.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata. org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikipedia.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org
            X509v3-Zertifikatsrichtlinien:
                Richtlinie: 2.23.140.1.2.1
                Richtlinie: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org ⓘ

            CT Vorzertifikat SCTs:
                Signiertes Zertifikat Zeitstempel:
                    Version : v1 (0x0)
                    Protokoll-ID : F6:5C:94:2F:D1:77:30:22:14:54:18:08:30:94:56:8E:
                                E3:4D:13:19:33:BF:DF:0C:2F:20:0B:CC:4E:F1:64:E3
                    Zeitstempel : Jul 15 09:01:49.274 2021 GMT
                    Erweiterungen: keine
                    Unterschrift : ecdsa-mit-SHA256
                                30:46:02:21:00:88:0F:F3:F1:BC:A3:AD:B8:7B:FD:C2:
                                A6:6A:4B:7C:1F:35:18:7B:3F:18:F6:43:29:46:F6:C2:
                                DD:15:63:C1:5D:02:21:00:CF:E0:1F:3D:E7:4A:37:C6:
                                CD:E5:BC:CD:99:FE:9C:F1:F7:EA:04:2D:97:DA:C2:74:
                                A6:30:37:57:F0:32:82:73
                Zeitstempel des signierten Zertifikats:
                    Version : v1 (0x0)
                    Protokoll-ID : 6F:53:76:AC:31:F0:31:19:D8:99:00:A4:51:15:FF:77:
                                15:1C:11:D9:02:C1:00:29:06:8D:B2:08:9A:37:D9:13
                    Zeitstempel : Jul 15 09:01:50.105 2021 GMT
                    Erweiterungen: keine
                    Unterschrift : ecdsa-mit-SHA256
                                30:44:02:20:37:BC:8F:6A:BA:FA:AC:0B:3B:4C:3F:C8:
                                C2:AB:EA:3B:60:DE:A8:AB:44:72:E5:43:6A:E0:0A:24:
                                32:49:7F:30:02:20:11:AF:F7:67:43:81:07:C7:FB:B6:
                                89:55:0B:74:58:61:76:FB:62:FF:F4:C9:D0:C6:A7:43:
                                63:98:4C:F5:4C:7E
    Unterschriftsalgorithmus: sha256WithRSAEncryption
         8e:f4:d1:85:9c:96:e8:63:d0:38:fd:7a:cc:d5:ad:b2:06:b4:
         4a:cf:3d:5a:b9:c2:28:3d:58:57:8a:55:42:ec:99:d3:ca:4f:
         ec:97:c0:10:73:77:43:5c:74:be:7e:2a:89:d8:fa:86:2f:8d:
         d3:57:99:67:3a:f6:28:6c:d1:26:29:ce:cf:7e:96:bd:34:0e:
         86:98:b3:0b:2e:28:dc:5b:46:77:32:a7:d9:b1:e6:de:e9:9a:
         2b:5d:03:f2:e0:07:12:03:d9:03:a8:ef:47:60:16:55:2a:32:
         53:c9:b3:4c:54:99:e0:98:d6:5f:1a:94:1c:6c:c5:e9:13:f7:
         08:c7:b6:b5:dd:d8:2b:b5:b7:2e:ba:cb:0b:2d:be:50:c6:85:
         0d:22:46:5e:e6:5f:b7:d4:86:45:d8:a4:bf:80:18:6e:46:96:
         d1:76:93:f5:40:e2:15:18:be:e0:cb:5f:cd:d0:4f:fa:ca:76:
         68:ba:94:c4:1d:1a:0e:3d:3b:ef:ed:1e:29:38:1d:22:bb:8b:
         96:71:55:b7:e4:8b:31:34:ec:63:09:e9:1c:d8:2f:f8:9a:b7:
         78:dc:33:c9:4e:84:85:03:0b:c5:52:af:9e:b0:6a:dc:fe:9e:
         89:2f:17:40:69:74:74:65:37:38:b4:28:23:01:01:81:19:23:
         23:cd:75:a0

Um dieses Endteilnehmer-Zertifikat zu validieren, benötigt man ein Zwischenzertifikat, das mit seinem Issuer und Authority Key Identifier übereinstimmt:

Aussteller C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 ⓘ
Identifikator des Behördenschlüssels 14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

Bei einer TLS-Verbindung würde ein ordnungsgemäß konfigurierter Server das Zwischenprodukt als Teil des Handshakes bereitstellen. Es ist jedoch auch möglich, das Zwischenzertifikat abzurufen, indem man die "CA Issuers"-URL aus dem Endteilnehmer-Zertifikat abruft. ⓘ

Zwischenzertifikat

Dies ist ein Beispiel für ein Zwischenzertifikat, das zu einer Zertifizierungsstelle gehört. Dieses Zertifikat hat das obige Endteilnehmerzertifikat signiert und wurde von dem unten stehenden Stammzertifikat signiert. Beachten Sie, dass das Betreff-Feld dieses Zwischenzertifikats mit dem Aussteller-Feld des von ihm signierten Endteilnehmer-Zertifikats übereinstimmt. Außerdem stimmt das Feld "Subject Key Identifier" im Zwischenzertifikat mit dem Feld "Authority Key Identifier" im Endteilnehmerzertifikat überein. 

Zertifikat:
    Daten:
        Version: 3 (0x2)
        Seriennummer:
            04:00:00:00:00:01:44:4e:f0:42:47
        Signatur-Algorithmus: sha256WithRSAEncryption
        Aussteller: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Gültigkeit
            Nicht vor: Feb 20 10:00:00 2014 GMT
            Nicht nach: Feb 20 10:00:00 2024 GMT
        Betreff: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organisationsvalidierung CA - SHA256 - G2
        Betreff Public Key Info:
            Öffentlicher Schlüssel Algorithmus: rsaEncryption
                Öffentlicher-Schlüssel: (2048 bit)
                Modulus:
                    00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:
                    ...
                Exponent: 65537 (0x10001)
        X509v3-Erweiterungen:
            X509v3 Schlüsselverwendung: kritisch
                Zertifikat signieren, CRL signieren
            X509v3 Basic Constraints: kritisch
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier:
                96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
            X509v3-Zertifikatsrichtlinien:
                Richtlinie: X509v3 Jede Richtlinie
                  CPS: https://www.globalsign.com/repository/

            X509v3 CRL-Verteilungspunkte:
                Vollständiger Name:
                  URI:http://crl.globalsign.net/root.crl

            Zugriff auf Autoritätsinformationen:
                OCSP - URI:http://ocsp.globalsign.com/rootr1

            X509v3 Authority Key Identifier:
                keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

    Unterschriftsalgorithmus: sha256WithRSAEncryption
         46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:
         ... ⓘ

Wurzelzertifikat

Dies ist ein Beispiel für ein selbstsigniertes Stammzertifikat, das eine Zertifizierungsstelle repräsentiert. Die Felder für Aussteller und Betreff sind identisch, und die Signatur kann mit dem eigenen öffentlichen Schlüssel validiert werden. Die Validierung der Vertrauenskette muss hier enden. Wenn das validierende Programm dieses Wurzelzertifikat in seinem Vertrauensspeicher hat, kann das Endteilnehmerzertifikat als vertrauenswürdig für die Verwendung in einer TLS-Verbindung angesehen werden. Andernfalls wird das Endteilnehmer-Zertifikat als nicht vertrauenswürdig eingestuft. 

Zertifikat:
    Daten:
        Version: 3 (0x2)
        Seriennummer:
            04:00:00:00:00:01:15:4b:5a:c3:94
        Signatur-Algorithmus: sha1WithRSAEncryption
        Aussteller: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Gültigkeit
            Nicht vor: Sep 1 12:00:00 1998 GMT
            Nicht nach: Jan 28 12:00:00 2028 GMT
        Betreff: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Betreff Public Key Info:
            Öffentlicher Schlüssel Algorithmus: rsaEncryption
                Öffentlicher-Schlüssel: (2048 bit)
                Modulus:
                    00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
                    ...
                Exponent: 65537 (0x10001)
        X509v3-Erweiterungen:
            X509v3 Schlüsselverwendung: kritisch
                Zertifikat signieren, CRL signieren
            X509v3 Basic Constraints: kritisch
                CA:TRUE
            X509v3 Subject Key Identifier: 
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    Signatur-Algorithmus: sha1WithRSAEncryption
         d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
         ... ⓘ

Sicherheit

Es gibt eine Reihe von Veröffentlichungen über PKI-Probleme von Bruce Schneier, Peter Gutmann und anderen Sicherheitsexperten. ⓘ

Architektonische Schwächen

  • Verwendung von Sperrlisten für ungültige Zertifikate (mit CRLs und OCSP),
    • Wenn der Client nur Zertifikaten vertraut, wenn CRLs verfügbar sind, verliert er die Offline-Fähigkeit, die PKI attraktiv macht. Die meisten Clients vertrauen also Zertifikaten, wenn keine CRLs verfügbar sind, aber in diesem Fall kann ein Angreifer, der den Kommunikationskanal kontrolliert, die CRLs deaktivieren. Adam Langley von Google hat gesagt, dass CRL-Prüfungen mit weichen Fehlern wie ein Sicherheitsgurt sind, der nur funktioniert, wenn man einen Unfall hat.
  • CRLs sind vor allem wegen ihres großen Umfangs und der unübersichtlichen Verteilungsmuster eine schlechte Wahl,
  • Mehrdeutige OCSP-Semantik und Fehlen eines historischen Widerrufsstatus,
  • Der Widerruf von Stammzertifikaten wird nicht behandelt,
  • Aggregationsproblem: Identitätsansprüche (Authentifizierung mit einer Kennung), Attributansprüche (Übermittlung einer Reihe geprüfter Attribute) und Richtlinienansprüche werden in einem einzigen Container kombiniert. Dies wirft Fragen des Datenschutzes, der Richtlinienzuordnung und der Wartung auf.
  • Delegationsproblem: CAs können untergeordnete CAs technisch nicht daran hindern, Zertifikate außerhalb eines begrenzten Namensraums oder Attributsatzes auszustellen; diese Funktion von X.509 wird nicht genutzt. Daher gibt es im Internet eine große Anzahl von Zertifizierungsstellen, deren Klassifizierung und deren Richtlinien eine unüberwindbare Aufgabe darstellen. Die Delegation von Befugnissen innerhalb einer Organisation kann überhaupt nicht gehandhabt werden, wie es in der Geschäftspraxis üblich ist.
  • Föderationsproblem: Zertifikatsketten, die das Ergebnis von untergeordneten CAs, Bridge-CAs und Cross-Signing sind, machen die Validierung komplex und teuer in Bezug auf die Verarbeitungszeit. Die Semantik der Pfadvalidierung kann mehrdeutig sein. Die Hierarchie mit einer dritten vertrauenswürdigen Partei ist das einzige Modell. Dies ist unpraktisch, wenn bereits eine bilaterale Vertrauensbeziehung besteht.
  • Die Ausstellung eines Extended Validation (EV)-Zertifikats für einen Hostnamen verhindert nicht die Ausstellung eines Zertifikats mit niedrigerer Validierung, das für denselben Hostnamen gültig ist, was bedeutet, dass die höhere Validierungsstufe von EV keinen Schutz vor Man-in-the-Middle-Angriffen bietet. ⓘ

Probleme mit Zertifizierungsstellen

  • Die Person oder Organisation, die ein Zertifikat erwirbt, wird oft die günstigste Zertifizierungsstelle nutzen. Als Reaktion darauf haben die Zertifizierungsstellen die Preise gesenkt und teurere Validierungsprüfungen abgeschafft, was als "Race to the Bottom" bekannt ist. Diesem Wettlauf nach unten wird teilweise durch Extended Validation (EV)-Zertifikate entgegengewirkt, deren Vertrauenswürdigkeit in den Augen von Sicherheitsexperten jedoch abnimmt. Laut Peter Gutmann bringen EV-Zertifikate keine zusätzlichen Sicherheitskontrollen. Vielmehr stellen EV-Zertifikate lediglich die Gewinne der Zertifizierungsstellen auf das Niveau vor dem "Race to the Bottom" wieder her, indem sie es den Zertifizierungsstellen ermöglichen, mehr Geld für eine Dienstleistung zu verlangen, die sie schon immer hätten anbieten sollen.
  • Zertifizierungsstellen versuchen, in ihren Zertifizierungsrichtlinien (Certification Practice Statement, CPS) fast alle Garantien für den Benutzer und die vertrauenden Parteien zu verweigern. Apple Inc. beispielsweise erklärt in seinem CPS: "Soweit gesetzlich zulässig, schließen die Abonnentenvereinbarungen, falls zutreffend, Garantien von Apple aus, einschließlich jeglicher Garantie der Marktgängigkeit oder der Eignung für einen bestimmten Zweck".
  • Laut Peter Gutmann "verwenden die Benutzer ein undefiniertes Protokoll für Zertifizierungsanfragen, um ein Zertifikat zu erhalten, das an einem unklaren Ort in einem nicht existierenden Verzeichnis veröffentlicht wird, ohne dass sie die Möglichkeit haben, es zu widerrufen".
  • Wie alle Unternehmen unterliegen auch die Zertifizierungsstellen den Rechtsordnungen, in denen sie tätig sind, und können rechtlich gezwungen sein, die Interessen ihrer Kunden und Nutzer zu gefährden. Auch Nachrichtendienste haben gefälschte Zertifikate, die durch außereheliche Kompromittierung von Zertifizierungsstellen wie DigiNotar ausgestellt wurden, für Man-in-the-Middle-Angriffe genutzt. Ein weiteres Beispiel ist ein Antrag auf Widerruf der Zertifizierungsstelle der niederländischen Regierung aufgrund eines neuen niederländischen Gesetzes, das am 1. Januar 2018 in Kraft tritt und den niederländischen Geheim- und Sicherheitsdiensten neue Befugnisse einräumt. ⓘ

Probleme bei der Implementierung

Die Implementierungen leiden unter Konstruktionsfehlern, Bugs, unterschiedlichen Auslegungen der Standards und mangelnder Interoperabilität der verschiedenen Standards. Einige Probleme sind:

  • Viele Implementierungen schalten die Widerrufsprüfung ab:
    • Dies wird als Hindernis angesehen, die Richtlinien werden nicht durchgesetzt.
    • Wenn sie in allen Browsern standardmäßig aktiviert wäre, einschließlich der Code-Signierung, würde dies wahrscheinlich die Infrastruktur zum Absturz bringen.
  • DNs sind komplex und werden kaum verstanden (fehlende Kanonisierung, Internationalisierungsprobleme)
  • rfc822Name hat zwei Notationen
  • Name und Policy Constraints werden kaum unterstützt
  • Schlüsselverwendung wird ignoriert, das erste Zertifikat in einer Liste wird verwendet
  • Die Durchsetzung von benutzerdefinierten OIDs ist schwierig
  • Attribute sollten nicht als kritisch eingestuft werden, da sie Clients zum Absturz bringen
  • Nicht spezifizierte Länge von Attributen führt zu produktspezifischen Beschränkungen
  • Es gibt Implementierungsfehler bei X.509, die z.B. gefälschte Subject-Namen mit null-terminierten Strings oder Code-Injection-Angriffe in Zertifikaten ermöglichen
  • Durch die Verwendung von illegalen 0x80-aufgefüllten Subidentifiern von Objekt-Identifikatoren, falschen Implementierungen oder durch Integer-Overflows der Client-Browser kann ein Angreifer ein unbekanntes Attribut in den CSR einfügen, das die CA signiert, und das der Client fälschlicherweise als "CN" (OID=2.5.4.3) interpretiert. Dan Kaminsky auf dem 26. Chaos Communication Congress "Schwarze OPs der PKI" ⓘ

Kryptographische Schwächen

Digitale Signatursysteme sind auf sichere kryptografische Hash-Funktionen angewiesen, um zu funktionieren. Wenn eine Public-Key-Infrastruktur die Verwendung einer Hash-Funktion zulässt, die nicht mehr sicher ist, kann ein Angreifer Schwachstellen in der Hash-Funktion ausnutzen, um Zertifikate zu fälschen. Wenn ein Angreifer in der Lage ist, eine Hash-Kollision zu erzeugen, kann er eine Zertifizierungsstelle davon überzeugen, ein Zertifikat mit harmlosem Inhalt zu signieren, wobei der Hash dieses Inhalts mit dem Hash eines anderen, bösartigen Satzes von Zertifikatsinhalten identisch ist, den der Angreifer mit Werten seiner Wahl erstellt hat. Der Angreifer kann dann die von der Zertifizierungsstelle bereitgestellte Signatur an den Inhalt seines bösartigen Zertifikats anhängen, wodurch ein bösartiges Zertifikat entsteht, das von der Zertifizierungsstelle unterzeichnet zu sein scheint. Da der Inhalt des böswilligen Zertifikats ausschließlich vom Angreifer ausgewählt wird, kann es andere Gültigkeitsdaten oder Hostnamen als das harmlose Zertifikat haben. Das bösartige Zertifikat kann sogar ein "CA: true"-Feld enthalten, das es in die Lage versetzt, weitere vertrauenswürdige Zertifikate auszustellen.

  • MD2-basierte Zertifikate wurden lange Zeit verwendet und waren anfällig für Preimage-Angriffe. Da das Stammzertifikat bereits mit einer Selbstsignatur versehen war, konnten Angreifer diese Signatur nutzen und für ein Zwischenzertifikat verwenden.
  • Im Jahr 2005 demonstrierten Arjen Lenstra und Benne de Weger, "wie man mit Hilfe von Hash-Kollisionen zwei X.509-Zertifikate konstruiert, die identische Signaturen enthalten und sich nur in den öffentlichen Schlüsseln unterscheiden", was durch einen Kollisionsangriff auf die MD5-Hash-Funktion erreicht wurde.
  • Im Jahr 2008 präsentierten Alexander Sotirov und Marc Stevens auf dem Chaos Communication Congress einen praktischen Angriff, der es ihnen ermöglichte, eine gefälschte Zertifizierungsstelle zu erstellen, die von allen gängigen Browsern akzeptiert wurde, indem sie die Tatsache ausnutzten, dass RapidSSL noch immer X.509-Zertifikate auf der Grundlage von MD5 ausstellte.
  • Im April 2009 präsentierten australische Forscher der Macquarie University auf der Eurocrypt-Konferenz "Automatic Differential Path Searching for SHA-1". Den Forschern gelang es, eine Methode abzuleiten, die die Wahrscheinlichkeit einer Kollision um mehrere Größenordnungen erhöht.
  • Im Februar 2017 gelang einer Gruppe von Forschern unter der Leitung von Marc Stevens eine SHA-1-Kollision, die die Schwäche von SHA-1 demonstrierte. ⓘ

Abhilfemaßnahmen für kryptografische Schwächen

Das Ausnutzen einer Hash-Kollision zum Fälschen von X.509-Signaturen setzt voraus, dass der Angreifer in der Lage ist, die Daten vorherzusagen, die die Zertifizierungsstelle signieren wird. Dies kann in gewissem Maße dadurch abgemildert werden, dass die Zertifizierungsstelle in den von ihr signierten Zertifikaten eine Zufallskomponente erzeugt, in der Regel die Seriennummer. Das CA/Browser Forum fordert seit 2011 in seinem Abschnitt 7.1 der Grundlegenden Anforderungen eine Entropie der Seriennummer. ⓘ

Seit dem 1. Januar 2016 verbieten die Grundlegenden Anforderungen die Ausstellung von Zertifikaten mit SHA-1. Seit Anfang 2017 lehnen Chrome und Firefox Zertifikate ab, die SHA-1 verwenden. Seit Mai 2017 lehnen auch Edge und Safari SHA-1-Zertifikate ab. X.509-Validierer, die nicht auf Browsern basieren, lehnen SHA-1-Zertifikate noch nicht ab. ⓘ

PKI-Standards für X.509

  • PKCS7 (Cryptographic Message Syntax Standard - öffentliche Schlüssel mit Identitätsnachweis für signierte und/oder verschlüsselte Nachrichten für PKI)
  • Transport Layer Security (TLS) und sein Vorgänger SSL - kryptographische Protokolle für die sichere Kommunikation im Internet.
  • Online Certificate Status Protocol (OCSP) / Zertifikatswiderrufsliste (CRL) - dient der Überprüfung des Zertifikatswiderrufsstatus
  • PKCS12 (Personal Information Exchange Syntax Standard) - wird verwendet, um einen privaten Schlüssel mit dem entsprechenden Zertifikat des öffentlichen Schlüssels zu speichern
  • Certification Path Building - Anleitung und Empfehlungen für den Aufbau von X.509 Public-Key-Zertifizierungspfaden innerhalb von Anwendungen (d.h. Validierung eines End-Entity-Zertifikats mithilfe eines CA-Zertifikats) ⓘ

PKIX-Arbeitsgruppe

1995 gründete die Internet Engineering Task Force in Zusammenarbeit mit dem National Institute of Standards and Technology die Public-Key Infrastructure (X.509) Working Group. Die Arbeitsgruppe, die im Juni 2014 abgeschlossen wurde, wird gemeinhin als "PKIX" bezeichnet. Sie erstellte RFCs und andere Standarddokumente zur Verwendung und zum Einsatz von X.509 in der Praxis. Insbesondere hat sie RFC 3280 und dessen Nachfolger RFC 5280 erstellt, die die Verwendung von X.509 in Internetprotokollen definieren. ⓘ

Wichtige Protokolle und Standards, die X.509-Zertifikate verwenden

TLS/SSL und HTTPS verwenden das RFC 5280-Profil von X.509, ebenso wie S/MIME (Secure Multipurpose Internet Mail Extensions) und die EAP-TLS-Methode zur WiFi-Authentifizierung. Jedes Protokoll, das TLS verwendet, wie z. B. SMTP, POP, IMAP, LDAP, XMPP und viele andere, verwendet von Haus aus X.509. ⓘ

IPSec kann das Profil RFC 4945 für die Authentifizierung von Peers verwenden. ⓘ

Die OpenCable-Sicherheitsspezifikation definiert ein eigenes Profil von X.509 für die Verwendung in der Kabelindustrie. ⓘ

Geräte wie Smart Cards und TPMs tragen oft Zertifikate, um sich selbst oder ihre Besitzer zu identifizieren. Diese Zertifikate liegen im X.509-Format vor. ⓘ

Der WS-Security-Standard definiert die Authentifizierung entweder über TLS oder über sein eigenes Zertifikatsprofil. Beide Methoden verwenden X.509. ⓘ

Das Microsoft Authenticode Code Signing System verwendet X.509, um die Autoren von Computerprogrammen zu identifizieren. ⓘ

Der Kommunikationsstandard OPC UA für die Industrieautomation verwendet X.509. ⓘ

SSH verwendet im Allgemeinen ein "Trust On First Use"-Sicherheitsmodell und benötigt keine Zertifikate. Die weit verbreitete OpenSSH-Implementierung unterstützt jedoch ein CA-signiertes Identitätsmodell, das auf seinem eigenen, nicht X.509-konformen Zertifikatsformat basiert. ⓘ

Beispiel für ein X.509-Zertifikat

Text-Darstellung eines nach X.509v3 (Version 3) aufgebauten digitalen Zertifikats. (Die Struktur basiert auf ASN.1.): 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=AT, ST=Steiermark, L=Graz, O=TrustMe Ltd, OU=Certificate Authority, CN=CA/Email=ca@trustme.dom
        Validity
            Not Before: Oct 29 17:39:10 2000 GMT
            Not After : Oct 29 17:39:10 2001 GMT
        Subject: C=AT, ST=Vienna, L=Vienna, O=Home, OU=Web Lab, CN=anywhere.com/Email=xyz@anywhere.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c4:40:4c:6e:14:1b:61:36:84:24:b2:61:c0:b5:
                    d7:e4:7a:a5:4b:94:ef:d9:5e:43:7f:c1:64:80:fd:
                    9f:50:41:6b:70:73:80:48:90:f3:58:bf:f0:4c:b9:
                    90:32:81:59:18:16:3f:19:f4:5f:11:68:36:85:f6:
                    1c:a9:af:fa:a9:a8:7b:44:85:79:b5:f1:20:d3:25:
                    7d:1c:de:68:15:0c:b6:bc:59:46:0a:d8:99:4e:07:
                    50:0a:5d:83:61:d4:db:c9:7d:c3:2e:eb:0a:8f:62:
                    8f:7e:00:e1:37:67:3f:36:d5:04:38:44:44:77:e9:
                    f0:b4:95:f5:f9:34:9f:f8:43
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                email:xyz@anywhere.com
            Netscape Comment:
                mod_ssl generated test server certificate
            Netscape Cert Type:
                SSL Server
    Signature Algorithm: md5WithRSAEncryption
        12:ed:f7:b3:5e:a0:93:3f:a0:1d:60:cb:47:19:7d:15:59:9b:
        3b:2c:a8:a3:6a:03:43:d0:85:d3:86:86:2f:e3:aa:79:39:e7:
        82:20:ed:f4:11:85:a3:41:5e:5c:8d:36:a2:71:b6:6a:08:f9:
        cc:1e:da:c4:78:05:75:8f:9b:10:f0:15:f0:9e:67:a0:4e:a1:
        4d:3f:16:4c:9b:19:56:6a:f2:af:89:54:52:4a:06:34:42:0d:
        d5:40:25:6b:b0:c0:a2:03:18:cd:d1:07:20:b6:e5:c5:1e:21:
        44:e7:c5:09:d2:d5:94:9d:6c:13:07:2f:3b:7c:4c:64:90:bf:
        ff:8e ⓘ
Abgerufen von „http://besserwiki.de/index.php?title=X.509&oldid=45475“