Struktur von X.509-Zertifikaten

Ein X.509-Zertifikat ist ein standardisiertes digitales Dokument, das einen öffentlichen Schlüssel an eine Identität bindet. Der X.509-Standard (definiert in RFC 5280) legt das Format, die Felder und die Erweiterungen fest, die weltweit in digitalen Zertifikaten verwendet werden. Jedes TLS-/HTTPS-Zertifikat, S/MIME-E-Mail-Zertifikat, Code-Signing-Zertifikat und Zertifikat zur Client-Authentifizierung folgt dem X.509-Format. Wenn Sie die Struktur eines X.509-Zertifikats verstehen, können Sie Zertifikatsinformationen lesen, Zertifikatsfehler diagnostizieren und fundierte Entscheidungen über die Bereitstellung und Validierung von Zertifikaten treffen.

Die ersten Felder eines X.509-Zertifikats legen seine grundlegenden Identitätsdaten fest. Version: X.509 v3 ist der aktuelle Standard (v3 hat Erweiterungen hinzugefügt). Seriennummer: eine von der ausstellenden CA vergebene eindeutige Ganzzahl, die dieses spezifische Zertifikat identifiziert – sie wird in CRLs (Sperrlisten) verwendet, um einzelne Zertifikate zu sperren. Signaturalgorithmus: legt den Algorithmus fest, mit dem die CA das Zertifikat signiert (z. B. sha256WithRSAEncryption oder ecdsa-with-SHA256). Dieses Feld erscheint zweimal: einmal im TBSCertificate und einmal in der äußeren Signaturstruktur – beide Angaben müssen übereinstimmen.

Zwei der wichtigsten Felder eines Zertifikats legen die beteiligten Parteien fest. Das Feld Issuer identifiziert die CA, die das Zertifikat signiert hat (z. B. CN=DigiCert Global CA G2, O=DigiCert Inc, C=US). Das Feld Subject identifiziert die Entität, für die das Zertifikat ausgestellt wurde (z. B. CN=*.example.com, O=Example Corp, C=US). Bei einem TLS-Zertifikat legt der Common Name (CN) des Subjects oder die Erweiterung Subject Alternative Name (SAN) fest, für welche Domain(s) das Zertifikat gültig ist. Browser gleichen den angeforderten Hostnamen mit diesen Feldern ab.

Der Gültigkeitszeitraum legt fest, wann das Zertifikat gültig ist. Er besteht aus zwei Zeitstempeln: notBefore (vor diesem Datum ist das Zertifikat noch nicht gültig) und notAfter (nach diesem Datum ist das Zertifikat abgelaufen). TLS-Clients prüfen, ob die aktuelle Zeit innerhalb dieses Zeitraums liegt. Zertifikate, die außerhalb ihres Gültigkeitszeitraums präsentiert werden, führen in Browsern zu einem Zertifikatsfehler und müssen erneuert werden. Eine moderne Best Practice ist die Ausstellung kurzlebiger Zertifikate (90 Tage, wie bei Let's Encrypt), um das Risiko zu begrenzen, falls ein privater Schlüssel zwischen Ausstellung und Ablauf kompromittiert wird.

Der zentrale Inhalt des Zertifikats befindet sich im Feld Subject Public Key Info. Es enthält den zu zertifizierenden öffentlichen Schlüssel und gibt den zugehörigen Algorithmus an. Bei einem RSA-Zertifikat enthält dieses Feld den Modulus und den Exponenten des öffentlichen RSA-Schlüssels sowie dessen Bitlänge (2048, 4096). Bei einem ECC-Zertifikat enthält es den Namen der elliptischen Kurve (z. B. prime256v1) und den öffentlichen Schlüsselpunk. Die CA erzeugt dieses Schlüsselpaar nicht – der Antragsteller des Zertifikats erzeugt sein eigenes Schlüsselpaar und übermittelt nur den öffentlichen Schlüssel in einer Certificate Signing Request (CSR).

X.509 v3 führte Erweiterungen ein, die die Funktionen von Zertifikaten erheblich erweitern. Erweiterungen können kritisch sein (ein Client, der diese Erweiterung nicht verarbeiten kann, muss das Zertifikat ablehnen) oder nicht kritisch (sie kann ignoriert werden, wenn sie nicht verstanden wird). Zu den wichtigsten Erweiterungen gehören: Subject Alternative Name (SAN) – zusätzliche Domainnamen oder IP-Adressen, für die das Zertifikat gilt; Key Usage – schränkt ein, für welche Vorgänge der Schlüssel verwendet werden darf (digitale Signatur, Schlüsselverschlüsselung); Extended Key Usage – schränkt den Verwendungszweck weiter ein (TLS-Serverauthentifizierung, Clientauthentifizierung, Codesignierung); und Basic Constraints – gibt an, ob das Subject eine CA ist.

Historisch wurde das Feld Common Name (CN) im Distinguished-Subject-Feld für den primären Domainnamen verwendet. Moderne Zertifikate verwenden stattdessen Subject Alternative Names (SANs), da Browser die CN-basierte Zuordnung (RFC 2818) zugunsten von SANs nicht mehr unterstützen. SANs ermöglichen es, mit einem einzigen Zertifikat mehrere Domains (Multi-SAN-Zertifikate) oder alle Subdomains einer Domain abzudecken (Wildcard-Zertifikate: *.example.com). SAN-Wildcards decken nur eine Ebene ab: *.example.com gilt für www.example.com, nicht aber für sub.www.example.com.

Zwei wichtige Erweiterungen teilen Clients mit, wie sie vor dem Ablaufdatum eines Zertifikats prüfen können, ob es gesperrt wurde. CRL Distribution Points (CDP): enthalten URLs, unter denen die Certificate Revocation List der CA heruntergeladen werden kann. Authority Information Access (AIA): enthält die URL des OCSP-Responders (Online Certificate Status Protocol) der CA für die Überprüfung des Sperrstatus in Echtzeit. Moderne Clients bevorzugen OCSP gegenüber dem Herunterladen von CRLs, da CRLs große Dateien sein können. Die digitale Signatur der CA auf OCSP-Antworten stellt sicher, dass Clients authentische Informationen zum Sperrstatus erhalten.

X.509-Zertifikate gibt es in mehreren Codierungsformaten, denen Sie in der Praxis begegnen werden. PEM (Privacy Enhanced Mail): Base64-codiertes DER, umschlossen von -----BEGIN CERTIFICATE------Headern. Menschenlesbar und unter Linux/Apache/nginx verwendet. DER (Distinguished Encoding Rules): Binärformat. Wird in Java-Anwendungen und einigen Windows-Kontexten verwendet. PFX/PKCS#12: ein Containerformat, das das Zertifikat, seine Kette und den privaten Schlüssel in einer passwortgeschützten Datei bündelt. Wird in Windows IIS und beim Exportieren von Zertifikaten zusammen mit ihren privaten Schlüsseln verwendet. P7B/PKCS#7: enthält nur die Zertifikatskette, keinen privaten Schlüssel, und wird in Windows-Zertifikatsspeichern verwendet.

Certificate Transparency (CT) ist ein Framework, das CAs dazu verpflichtet, alle ausgestellten Zertifikate in öffentlich überprüfbaren Logs zu protokollieren. Dadurch kann jeder nach nicht autorisierten Zertifikaten suchen, die für die eigenen Domains ausgestellt wurden. Chrome und Safari verlangen, dass TLS-Zertifikate in CT-Logs enthalten sind. Ein SCT (Signed Certificate Timestamp) ist ein Nachweis für die Aufnahme in ein Log. Er ist entweder in das Zertifikat eingebettet oder wird über eine TLS-Erweiterung übermittelt. CT-Logs machen fehlerhafte Ausstellungen schnell sichtbar – wenn eine CA fälschlicherweise ein Zertifikat für Ihre Domain ausstellt, sehen Sie es in Logs wie crt.sh, bevor Angreifer es missbrauchen können.

Die letzte Komponente eines X.509-Zertifikats ist die digitale Signatur der CA. Die CA bildet einen Hash über alle Zertifikatsdaten (TBSCertificate) und signiert diesen Hash mit ihrem eigenen privaten Schlüssel. Diese Signatur macht das Zertifikat vertrauenswürdig – jeder kann sie mit dem öffentlichen Schlüssel der CA überprüfen, der im eigenen Zertifikat der CA enthalten ist. Der verwendete Signaturalgorithmus (im Signaturfeld aufgeführt) muss mit der früher im Zertifikat angegebenen Variante übereinstimmen. Jede Änderung am Zertifikat nach der Signierung macht die Signatur ungültig und gewährleistet dadurch die Integrität des Zertifikats.

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

In dieser Lektion haben Sie gelernt: Ein X.509-Zertifikat enthält Version, Seriennummer, Aussteller, Subject, Gültigkeitszeitraum, öffentlichen Schlüssel und v3-Erweiterungen; die SAN-Erweiterung legt fest, für welche Hostnamen das Zertifikat gilt; CDP- und AIA-Erweiterungen verweisen auf Endpunkte zur Prüfung des Sperrstatus; und CT-Logs bieten öffentlich überprüfbare Protokolle über die Ausstellung von Zertifikaten. Als Nächstes sehen wir uns den Lebenszyklus und die Sperrung von Zertifikaten an.