X.509 ist ein Standard , der Formate für Public-Key- Zertifikate, Zertifikatsperrlisten, Zertifikatattribute und einen von der International Telecommunication Union (ITU) definierten Algorithmus zur Validierung von Zertifizierungspfaden angibt . X.509 legt unter anderem ein elektronisches Standardzertifikatformat und einen Algorithmus zur Validierung des Zertifizierungspfads fest. X.509 war auch zahlreiche RFCs der IETF .
X.509 wurde 1988 als Teil des X.500- Standards erstellt . Es basiert auf einem hierarchischen System von Zertifizierungsstellen , im Gegensatz zu vertrauenswürdigen Netzwerken (wie dem OpenPGP -Vertrauensnetz ), in denen jeder die Zertifikate anderer signieren kann.
In dem X.509 - System, eine Zertifizierungsstelle Abtretungsempfänger ein Zertifikat einen öffentlichen Schlüssels an einen Bindungs Distinguished Namen , dessen Formats durch die definierte X.500 Empfehlung oder auf einen alternativen Namen ( Alternative Namen ) , wie beispielsweise ‚‘ eine E - Mail - Adresse oder DNS aufnehmen .
Dieses Zertifikat setzt die Unterschrift einer Zertifizierungsstelle in das letzte Feld. Konkret erfolgt diese Signatur durch ein Kondensat aller vorhergehenden Felder des Zertifikats und eine Verschlüsselung dieses Kondensats durch den privaten Schlüssel der Zertifizierungsstelle. Jeder mit dem öffentlichen Schlüssel für diese Zertifizierungsstelle kann den Hash entschlüsseln und mit seiner eigenen Zertifikat-Hash-Berechnung vergleichen. Wenn die beiden Kondensate identisch sind, wird garantiert, dass das Zertifikat intakt ist und nicht geändert wurde. Das Zertifikat der Zertifizierungsstelle, das ihren öffentlichen Schlüssel enthält, kann wiederum von einem anderen übergeordneten Zertifikat signiert werden, wodurch eine Kette gebildet wird. An der Spitze der Kette stehen die wichtigsten Zertifikate : Stammzertifikate .
Stammzertifikate sind nicht signierte oder selbstsignierte öffentliche Schlüssel , denen Sie vertrauen. Software wie Webbrowser oder E-Mail-Clients enthalten Stammzertifikate von vielen kommerziellen oder staatlichen Zertifizierungsstellen. Wenn ein Browser eine sichere Verbindung ( TLS / SSL ) zu einer Site öffnet , für die ein Zertifikat von einer bekannten Behörde ausgestellt wurde, betrachtet er die Site als sicher, solange der Zertifizierungspfad validiert ist. Das Umschalten in den sicheren Modus ist dann transparent.
Wenn die Software (Browser oder andere) die Zertifizierungsstelle nicht kennt (Zertifikat erstellt und selbstsigniert von einer Person oder Zertifizierungsstelle, die noch nicht bekannt ist oder freiwillig aus der Liste der anerkannten Behörden entfernt wurde), schlägt der Browser vor, das Zertifikat zu prüfen Akzeptieren oder ablehnen Sie es je nach dem ihm entgegengebrachten Vertrauen.
X.509 kann mit S / MIME , TLS / SSL , SET und IPsec verwendet werden .
Die ursprüngliche Definition ist in RFC 2459 (Abschnitt 4) oder in der neuesten Version ( RFC 5280) verfügbar , die eine Spezialisierung von X.509 für Internetanwendungen enthält . Der authentifizierte Teil enthält die folgenden Felder:
Die Namen des Absenders (auch Unterzeichner) und des Inhabers sind X.501-Namen, die auch in ISO- und LDAP- Verzeichnissen enthalten sind . Dem obigen Inhalt folgt eine Wiederholung des Signaturalgorithmus und der Signatur selbst.
Nichts in den Pflichtfeldern erlaubt es, eine Zertifizierungsstelle (eine Organisation, die Zertifikate ausstellt) von einem einfachen Inhaber zu unterscheiden. Die in X.509 Version 3 definierte Erweiterung basicConstraints behebt diese Einschränkung. Eine weitere Unzulänglichkeit des gleichen Typs besteht darin, dass nur der Name die Verknüpfung eines Zertifikats mit dem seines Ausstellers ermöglicht, während die Eindeutigkeit von Namen nicht garantiert werden kann.
Der RFC 5280 definiert eine Summe von Erweiterungen, die die beabsichtigte Verwendung des Zertifikats angeben. Hier sind die häufigsten Erweiterungen:
Wenn ein Zertifikat mehrere Erweiterungen aufweist, die seine Verwendung einschränken, müssen im Allgemeinen alle Bedingungen erfüllt sein, damit die Verwendung angemessen ist. Der RFC 5280 enthält das spezifische Beispiel eines Zertifikats, das beide keyUsage extendedKeyUsage enthält. In diesem Fall müssen die beiden Einschränkungen erfüllt sein, damit das Zertifikat gemäß den beabsichtigten Verwendungszwecken verwendet werden kann.
Hier sind die allgemeinen Erweiterungen von Zertifikaten im X.509-Format:
Eine Zertifikatskette ist eine Liste von Zertifikaten (beginnend mit einer zu zertifizierenden Entität wie einem Server), die eine oder mehrere Zertifizierungsstellen umfasst (die letzte wird von sich selbst signiert) und die folgenden Eigenschaften aufweist:
Zertifikatketten verwendet werden , um sicherzustellen , dass der öffentliche Schlüssel und Zertifikatsdaten (die 1 st der Kette) entspricht den Besitzer davon. Um dies sicherzustellen, wird die digitale Signatur mithilfe des öffentlichen Schlüssels der nächsten Entität in der Kette überprüft, der selbst vom öffentlichen Schlüssel der nächsten Entität signiert ist, bis die letzte Entität der Kette erreicht ist. Als das letzte Zertifikat vertrauenswürdig angesehen wird, letztlich darauf zurückgehen beträgt das zum Authentifizieren 1 st Zertifikats.
Ein Zertifikat kann aus vielen Gründen ungültig werden, z. B. aufgrund des natürlichen Ablaufs (Überschreitung des Gültigkeitsdatums), des Verlusts oder der Beeinträchtigung des mit dem Zertifikat verbundenen privaten Schlüssels, der Änderung mindestens eines Felds im Namen des Zertifikatsinhabers / -inhabers und des Extremfalls Verlust oder Kompromittierung des privaten Schlüssels der Zertifizierungsstelle , die das betreffende Zertifikat unterzeichnet hat.
Aus diesem Grund definiert der Standard das Format einer Liste, in der die Zertifikate angegeben sind, die für eine bestimmte Zertifizierungsstelle ungültig geworden sind. Diese Liste wird von der Zertifizierungsstelle unterzeichnet, um Änderungen durch unbefugte Personen zu verhindern.
Es enthält ein Ausstellungsdatum, ein Aktualisierungsdatum (beide optional) und die Liste selbst in Form von Paaren (Seriennummer des widerrufenen Zertifikats; möglicher Grund für den Widerruf) . Das Muster kann nur in CRLs im Format Version 2 vorhanden sein.
Eine manchmal ärgerliche Einschränkung von CRLs ist die Verzögerung bei der Weitergabe von Sperrinformationen. Um dies zu reduzieren, wurde das OCSP- Zertifikatvalidierungsprotokoll entwickelt. Dieses Protokoll wurde zunächst in RFC 2560 und dann wieder in RFC 6960 definiert und liefert ungefähr die gleichen Informationen wie CRLs, ist jedoch möglicherweise aktueller.
Nach der Veröffentlichung eines vollständigen Kollisionssuche Angriff gegen MD5 2004 Arjen Lenstra , Wang Xiaoyun, und Benne de Weger wurde in X.509 mit MD5 für die Zertifikatsauthentifizierung interessiert. Ihr Angriff führte zur Fälschung von zwei Zertifikaten mit identischen Signaturen.
Die Verwendung der kryptografischen SHA-1- Hash- Funktion löst das Problem nur teilweise, da ein ähnlicher Angriff theoretisch möglich ist, obwohl die Komplexität des Auffindens von Kollisionen auf SHA-1 viel größer ist als auf MD5.
Lösungen:
Zertifizierungsstellen:
Tools (kostenlos):