X.509X.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[1] 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. GeschichteX.509 wurde erstmals 1988 veröffentlicht. Die Entwicklung von X.509 begann in Verbindung mit dem X.500-Standard, der nie vollständig implementiert wurde. X.509 setzt ein strikt hierarchisches System von vertrauenswürdigen Zertifizierungsstellen (englisch certificate authority, CA) voraus, die Zertifikate erteilen können. Dieses Prinzip steht im Gegensatz zum Web-of-Trust-Modell, welches einen Graphen und nicht nur einen Baum darstellt und bei dem jeder ein Zertifikat „unterschreiben“ und damit seine Echtheit beglaubigen kann (siehe z. B. OpenPGP). Version 3 von X.509 (X.509v3) beinhaltet die Flexibilität, mit Profilen erweitert zu werden. Die IETF entwickelte das wichtigste Profil, PKIX Certificate and CRL Profile, kurz „PKIX“, im Rahmen des RFC 3280,[2] aktuell RFC 5280.[3] Der Begriff „X.509-Zertifikat“ bezieht sich meist darauf. ZertifikateEin von einer Zertifizierungsstelle ausgestelltes digitales Zertifikat wird im X.509-System immer an einen „Distinguished Name“ oder einen „Alternative Name“ wie eine E-Mail-Adresse oder einen DNS-Eintrag gebunden. Nahezu alle Webbrowser enthalten eine vorkonfigurierte Liste vertrauenswürdiger Zertifizierungsstellen, deren X.509-Zertifikaten der Browser vertraut. Umgangssprachlich wird häufig von SSL-Zertifikaten gesprochen. X.509 beinhaltet außerdem einen Standard, mittels dessen Zertifikate seitens der Zertifizierungsstelle wieder ungültig gemacht werden können, wenn deren Sicherheit nicht mehr gegeben ist (z. B. nach dem öffentlichen Bekanntwerden des privaten Schlüssels für das Signieren von E-Mails). Die Zertifizierungsstelle kann hierfür ungültige Zertifikate in Zertifikatsperrlisten (certificate revocation list, kurz CRL) führen. Die automatische Überprüfung, ob ein Zertifikat inzwischen Teil einer Sperrliste ist, ist allerdings nicht in allen Programmen, die X.509-Zertifikate akzeptieren, standardmäßig aktiviert. Struktur eines X.509-v3-Zertifikats
Aussteller und Zertifikatinhaber werden jeweils durch eine Reihe von Attributen charakterisiert:
Aussteller- und Inhaber-ID wurden in Version 2 eingeführt, Erweiterungen in Version 3. ErweiterungenErweiterungen oder Extensions sind inzwischen ein sehr wichtiger Bestandteil eines Zertifikates geworden. Erweiterungen haben die folgende Unterstruktur:
Jede Erweiterung hat eine spezifische ID. Die Flags dienen der schrittweisen Einführung einer neuen Erweiterung. So sind neue Erweiterungen zu Beginn als unkritisch markiert. Eine Implementierung, die auf eine unbekannte unkritische Erweiterung trifft, kann diese ignorieren. Wird eine Erweiterung mit der Zeit allerdings nach ausreichendem Testen auf kritisch gesetzt, so muss ein Zertifikat mit unbekannter kritischer Erweiterung als ungültig erachtet werden. Beispiele für Erweiterungen sind
Dateinamenserweiterungen für ZertifikateÜbliche Dateinamenserweiterungen für X.509-Zertifikate sind:
PKCS #7 ist ein Standard zum Signieren und Verschlüsseln von Daten. Da das Zertifikat gebraucht wird, um die signierten Daten zu verifizieren, kann es in der „SignedData“-Struktur untergebracht werden. Eine PKCS #12 entwickelte sich aus dem PFX-Standard (Personal inFormation eXchange) und wird benutzt, um öffentliche und private Schlüssel in einer gemeinsamen Datei auszutauschen. Eine Beispiel für ein X.509-ZertifikatText-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 Literatur
Weblinks
Einzelnachweise
|