X.509 ist ein ITU-IT-Standard für eine Public-Key-Infrastruktur (PKI)
und derzeit der wichtigste Standard für digitale Zertifikate. Die aktuelle
Version ist X.509v3.
X.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)
und setzt ein striktes hierarchisches System von vertrauenswürdigen
Zertifizierungsstellen (engl. "Certificate authority", kurz
"CA") voraus, die Zertifikate erteilen können. Dieses Prinzip steht
im Kontrast zu dem Web of Trust-Modell, bei dem jeder (nicht nur spezielle
Zertifizierungsstellen) ein Zertifikat "unterschreiben" und damit
seine Echtheit beglaubigen kann (siehe z. B. PGP).
Version 3 von x.509 (X.509v3) beinhaltet die Flexibilität, mit Profilen
erweitert zu werden. Das wichtigste Profil entwickelte die IETF* im Zusammenhang
mit dem PKIX-Standard. Der Begriff "X.509-Zertifikat" bezieht sich meist auf
das IETF-Profil des X.509-v3-Zertifikatsstandards wie in RFC 3280 definiert.
*Die IEF (Internet Engineering Task Force) ist eine Arbeitsgruppe des
Internet Architecture Board (IAB). Ihr Auftrag besteht in der Entwicklung und
Förderung von Internetstandards, insbesondere die der TCP/IP-Familie.
Zertifikate
In dem X.509-System bestätigt eine Zertifizierungsstelle durch die
Ausstellung eines Zertifikats, dass ein öffentlicher Schlüssel zu einem
bestimmten "Distinguished Name" (in X.500-Standard) oder zu einem
"Alternative Name" wie z. B. einer E-Mail-Adresse oder einem
DNS-Eintrag gehört.
Nahezu alle Webbrowser beinhalten eine vorkonfigurierte Liste
vertrauenswürdiger Zertifizierungsstellen, deren ausgestellten SSL-Zertifikaten
der Browser vertraut. Obwohl grundsätzlich für den Benutzer die Möglichkeit
besteht, diese Listen zu bearbeiten, wird in den allerwenigsten Fällen Gebrauch
von dieser Möglichkeit gemacht.
X.509 beinhaltet außerdem einen Standard, Zertifikate seitens der
Zertifizierungsstelle wieder ungültig zu machen, indem die
Zertifizierungsstelle ungültige Zertifikate in Zertifikatssperrlisten (Certificate
Revocation List", kurz "CRL") führt. Erklärt eine
Zertifizierungsstelle ein Zertifikat für ungültig, trägt es die Seriennummer
dieses Schlüssels in die Zertifikatssperrliste ein. Diese wird dann abgefragt,
wenn ein ein Programm bei der Zertifizierungsstelle anfragt, ob ein bestimmtes
Zertifikat gültig ist (was vor jeder Verwendung des Schlüssels geschehen
sollte). Eine andere Möglichkeit zur Überprüfung der Gültigkeit eines
Zertifikats besteht in der Verwendung des neueren "Online Certificate
Status Protocol (OSCP)".
Struktur eines X-509-v3-Zertifikats
Zertifikat
Version
Seriennummer
Algorithmen ID
Aussteller
Gültigkeit
von
bis
Subject
Subject Public Key Info
Public Key Algorithmus
Subject Public Key
Eindeutige ID des Ausstellers (optional)
Eindeutige ID des Inhabers (optional)
Erweiterungen
....
Zertifikat Signaturalgorithmus
Zertifikat Signatur
Herausgeber- und Inhaber-ID wurden in Version 2 eingeführt,
Erweiterungen in Version 3.
Erweiterungen oder Extensions sind inzwischen ein sehr wichtiger Bestandteil
eines Zertifikates geworden. Erweiterungen haben die folgende Unterstruktur:
Erweiterungs-ID
Flag (kritisch/unkritisch)
Value
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
KeyUsage: gibt an, für welche Anwendung dieses Zertifikat ausgestellt
wurde. Ein CA-Zertifikat muss hier bspw. keyCertSign und CRLsign eingetragen
haben
BasicConstraints: Transitivitätsvertrauen ist ohne diese Erweiterung unmöglich.
Die BasicContraints bestehen aus
CA: gibt an, ob das Zertifikat zu einer CA gehört. In einer
Zertifikatskette muss jedes Zertifikat außer dass der letzten Instanz
(des Users/Servers) als CA markiert sein
PathLen: gibt an, wie lang die Zertifikatskette maximal sein darf
Dateinamenerweiterungen für Zertifikate
Übliche Dateinamenerweiterungen für X.509-Zertifikate sind:
.CER - CER-kodiertes Zertifikat oder Zertifikatsfolgen
.DER - DER-kodiertes Zertifikat
.PEM - Base64-kodiertes Zertifikat, umschlossen von "-----BEGIN CERTIFICATE-----"
und "-----END CERTIFICATE-----"
.P7B - Siehe .p7c
.P7C - PKCS#7 Signierte Datenstruktur ohne Dateninhalt, nur mit
Zertifikat(en) oder Zertifikatssperrliste(n)
.PFX - Siehe .p12
.P12 - PKCS#12, kann öffentliche Zertifikate und private Schlüssel
(kennwort-geschützt) enthalten.
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 .p7c-Datei ist der Spezialfall einer Zertifikatsdatei, die keine Daten
zum Signieren enthält, sondern nur die "SignedData"-Struktur.
Verwendet in PDF-Dateien von Adobe Acrobat bis
einschließlich Version 5.0
PKCS #12
entwickelte sich aus dem PFX (Personal inFormation eXchange)-Standard
und wird benutzt, um öffentliche und private Schlüssel in einer
gemeinsamen Datei auszutauschen. Dieser Zertifikatstyp wird am häufigsten
zum digitalen Signieren von PDF-Dateien verwendet.
Verwendet in PDF-Dateien von Adobe Acrobat ab Version 6.0
Eine .PEM-Datei kann Zertifikate oder private Schlüssel enthalten, die von
entsprechenden BEGIN/END-Zeilen umschlossen sind.
Beispiel für X.509-Zertifikate
Als Beispiel für ein X.509-Zertifikat ist hier die decodierte (mit openssl
generierte) Version eines der alten Zertifikate von www.freesoft.org
dargestellt; das eigentliche Zertifikat hat eine Größe von ca. 1 KB. Gemäß
der Information in dem Feld Issuer (Austeller) wurde das Zertifikat von Thawte
(mittlerweile von Verisign übernommen) ausgestellt (signiert). Das "Subject"-Feld
enthält eine Menge persönlicher Informationen, wichtig ist hier aber vor allem
der CN (Common Name)-Eintrag von www.freesoft.org - dieser Teil muss mit dem
Host, dessen Echtheit durch die Signatur bestätigt wird, übereinstimmen.
Anschließend kommen die Informationen zu dem öffentlichen RSA-Schlüssel (RSA-PublicKey)
(Modulus und Exponent), gefolgt von der Signatur. Zur Erstellung der Signatur
wurde zunächst ein MD5-Hash von den in dem ersten Teil des Zertifikats
enthaltenen Informationen erstellt und dieser anschließend mit dem privaten
RSA-Schlüssel (RSA private Key) von Thawte verschlüsselt.
Um die Echtheit dieses Zertifikats zu prüfen, wird ein weiteres Zertifikat
einer Zertifizierungsstelle benötigt, eines, das die Authentizität des Ausstellers
(Thawte Server CA) des ersten
Zertifikats bestätigt (siehe Abbildung unten). Der öffentliche RSA-Schlüssel
aus dem zweiten Zertifikat wird jetzt verwendet, um die Signatur des ersten
Zertifikats zu decodieren, um einen MD5-Hash zu erhalten. Dieser MD5-Hash muss
mit einem aktuell aus den restlichen Informationen des ersten Zertifikats
berechneten MD5-Hash übereinstimmen.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Validity
Not Before: Aug 1 00:00:00 1996 GMT
Not After : Dec 31 23:59:59 2020 GMT
Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
OU=Certification Services Division,
CN=Thawte Server CA/Email=server-certs@thawte.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
3a:c2:b5:66:22:12:d6:87:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
70:47
Dies ist ein Beispiel für ein selbst-signiertes Zertifikat; daran zu
erkennen, dass Aussteller und Subject identisch sind. Es gibt keine
Möglichkeit, dieses Zertifikat zu verifizieren, außer man prüft es gegen sich
selbst. Damit ist die oberste Stelle in der Zertifizierungskette erreicht. Doch
wie wird solch ein Zertifikat vertrauenswürdig? Ganz einfach - es ist manuell
konfiguriert. Thawte gehört zu einer der von Microsoft und Netscape anerkannten
vertrauenswürdigen Stammzertifizierungsstellen. Dieses Zertifikat ist in der
vorinstallierten Zertifikatsliste der meisten Webbrowser enthalten (zu
finden z. B. im Windows Internet Explorer > Internetoptionen > Inhalte
> Zertifikate > Stammzertifikate > "Thawte Server CA"); ihm
wird "standardmäßig" vertraut. Auf Grund seiner langen
Gültigkeitsdauer (siehe Informationen unter "Validity") und der Tatsache, dass mit diesem global
vertrauenswürdige Zertifikat so gut wie alles signiert werden kann (siehe
keinerlei Bedingungen unter "Constraints"), muss der
zugehörige private/geheime Schlüssel zu den weltweit best geschützten und am
sichersten verwahrten
Schlüsseln gehören.
Zertifizierungsstelle
Eine Zertifizierungsstelle (englisch Certificate Authority,
kurz CA) ist eine Organisation, die digitale Zertifikate herausgibt. Ein
digitales Zertifikat ist gewissermaßen das Cyberspaceäquivalent eines
Personalausweises und dient dazu, einen bestimmten öffentlichen Schlüssel
einer Person oder Organisation zuzuordnen. Diese Zuordnung wird von der
Zertifizierungsstelle beglaubigt, indem sie sie mit ihrer eigenen digitalen
Unterschrift versieht.
Die Zertifikate enthalten "Schlüssel" und Zusatzinformationen, die zur
Authentifizierung sowie zur Verschlüsselung und Entschlüsselung sensitiver
oder vertraulicher Daten dienen, die über das Internet und andere Netze
verbreitet werden. Als Zusatzinformationen sind zum Beispiel Lebensdauer,
Verweise auf Zertifikatssperrlisten etc. enthalten, die durch die CA mit in das
Zertifikat eingebracht werden.
Die Aufgabe einer Beglaubigungsinstitution ist es, solche digitalen
Zertifikate herauszugeben und zu überprüfen. Sie ist dabei für die
Bereitstellung, Zuweisung und Integritätssicherung der von ihr ausgegebenen
Zertifikate verantwortlich. Damit ist sie ein wichtiger Teil der
Public-Key-Infrastruktur.
Eine Zertifizierungsstelle kann sowohl ein spezielles Unternehmen darstellen
(z. B. GlobalSign/ Cybertrust Verisign) oder eine Institution innerhalb eines
Unternehmens, das einen eigenen Server installiert hat (ein Beispiel hierfür
ist der Microsoft Certificate Server). Auch öffentliche Organisationen oder
Regierungsstellen können als Zertifizierungsstelle dienen, z.B. in Deutschland
die Bundesnetzagentur.
Literatur
ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems
Interconnection - The Directory: Authentication Framework, June 1997.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key
Infrastructure: Certificate and CRL Profile", RFC 2459, January 1999.
Housley, R., W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key
Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002.
Siehe auch
Digitales Zertifikat
Digitale Signatur
Public Key (Öffentlicher Schlüssel)
Public-Key-Infrastruktur (PKI)
Zertifizierungssstelle (Certificate Authority)
PGP (Pretty Good Privacy)
Online Certificate Status Protocol (OCSP)
Zertifikatssperrliste (CRL)
Protokolle und Standards, die
X.509-Zertifikate unterstützen
SSL/TLS (Transport Layer Security)
S/MIME (Secure Multipurpose Internet Mail Extensions)
IPSec
SSH
Smartcard
HTTPS
EAP
LDAPv3
Trusted Computing Group (TNC TPM NGSCB)
WS-Security (Microsoft und andere)
CableLabs (North American Cable Industry Technology Forum)