Worum geht’s
Ein abgelaufenes Zertifikat, ein falscher Hostname, ein unerwarteter Aussteller — solche Befunde stecken im Zertifikat selbst. Wer ein X.509-Zertifikat liest, kann Browser-Warnungen erklären, ein Monitoring-Ticket einordnen und beurteilen, ob ein Zertifikat zu einem Dienst passt. Dieser Skill ist die Lese-Routine für genau diese Fragen.
Konzept
Ein X.509-Zertifikat bindet einen öffentlichen Schlüssel an eine Identität und ist von einer CA signiert. Die wichtigsten Felder:
- Subject: für wen das Zertifikat gilt (DN mit
CN, oftO/C). - Subject Alternative Names (SAN): die verbindliche Hostnamen-Liste (
DNS:-Einträge). Der aufgerufene Host muss hier vorkommen, sonst meldet der Browser einen Namensfehler. - Issuer: welche CA es ausgestellt hat. Bei Selbstsignierung ist Issuer = Subject.
- Gültigkeit:
notBefore/notAfter. Außerhalb dieses Fensters ist das Zertifikat ungültig („abgelaufen” ist die häufigste Ursache für TLS-Warnungen). - Key Usage / Extended Key Usage: wofür der Schlüssel genutzt werden darf (z. B.
digitalSignature,keyEncipherment; EKUserverAuthfür TLS-Server). - Basic Constraints:
CA:TRUE(darf weitere Zertifikate signieren) vs.CA:FALSE(End-Entity/Leaf). - Fingerprint (SHA-256 über das DER): eindeutige Kennung zum Wiedererkennen/Abgleichen.
Wichtig: Ein gültig lesbares Zertifikat ist nicht automatisch vertrauenswürdig — dazu muss die ganze Kette bis zu einer bekannten Root prüfbar sein (eigener Skill).
Diese Felder machen ein X.509-Zertifikat aus:
- Subject / SAN — 30%
- Issuer — 20%
- Gültigkeit — 20%
- Key Usage / EKU — 20%
- Signatur — 10%
Beispiel-Fall
Aufgabe: Ein Monitoring meldet „Zertifikatsproblem” für api.firma.de. Du analysierst.
- Zertifikat im Decoder einlesen und Gültigkeit prüfen: liegt
notAfterin der Zukunft? Abgelaufen → Erneuerung anstoßen. - SAN prüfen: Steht
api.firma.dealsDNS:-Eintrag drin? Fehlt er → Namensfehler, falsches Zertifikat im Einsatz. - Issuer ansehen: Eine bekannte CA oder ein internes/selbstsigniertes Zertifikat? Letzteres erklärt Browser-Warnungen außerhalb der eigenen Trust-Umgebung.
- EKU prüfen: Ist
serverAuthgesetzt? Ohne passende Verwendung ist das Zertifikat für TLS-Server ungeeignet. - Befund mit Ursache und Maßnahme dokumentieren.
Anwenden
Notiere den SHA-256-Fingerprint — damit erkennst du dasselbe Zertifikat später eindeutig wieder.
- Füge ein Zertifikat im PEM-Format ein und lies Subject, Issuer und Gültigkeit (notBefore/notAfter).
- Prüfe die SAN-Liste, ob der relevante Hostname enthalten ist.
- Sieh dir Key Usage / EKU und Basic Constraints (CA:TRUE/FALSE) an.
Selbsttest
Praxis-Challenge
Exportiere ein Server-Zertifikat einer beliebigen HTTPS-Seite (Browser → Zertifikat anzeigen → exportieren) und lies es im Decoder. Beantworte: Wer ist Issuer, wann läuft es ab, welche Hosts deckt die SAN ab und ist EKU serverAuth gesetzt? Formuliere ein kurzes Urteil zur Eignung.