📜Zertifikate & PKI
Der Schlüsselaustausch schützt vor Lauschern – aber nicht vor einem Angreifer in der Mitte, der sich als www.example.org ausgibt. Dagegen hilft das Zertifikat: eine von einer vertrauenswürdigen Stelle signierte Aussage „dieser öffentliche Schlüssel gehört zu diesem Namen“.
🧬Aufbau eines X.509-Zertifikats
issuer
Distinguished Name der ausstellenden CA. Muss exakt dem Subject des Ausstellerzertifikats entsprechen – so wird die Kette gebaut.
⏳ erzeuge Zertifikat …
⛓️Zertifikatskette prüfen
🏛️Vertrauensspeicher (Trust Store)
🚫Sperrung: CRL, OCSP, Stapling
| Verfahren | So funktioniert es | Vorteil | Nachteil |
|---|---|---|---|
| CRL | CA veröffentlicht signierte Liste gesperrter Seriennummern (URL im Zertifikat: cRLDistributionPoints) | keine Anfrage pro Besuch → datenschutzfreundlich | Listen können groß sein; Browser verteilen komprimierte Auszüge (Chrome CRLSets, Firefox CRLite) |
| OCSP | Client fragt die CA online: „Ist Seriennummer X gesperrt?“ | aktuell | CA erfährt, wer welche Seite besucht; bei Ausfall meist „soft-fail“ (wird ignoriert) |
| OCSP Stapling | Server holt die signierte OCSP-Antwort selbst und liefert sie im Handshake mit (status_request) | keine Datenschutzlücke, schnell | nur wenn die CA OCSP anbietet – Let's Encrypt hat OCSP am 06.08.2025 abgeschaltet |
| kurze Laufzeit | Zertifikat läuft einfach bald ab (z. B. 6 Tage) | kein Sperrmechanismus nötig | setzt vollautomatische Erneuerung voraus |
📚 Quelle: Let's Encrypt: Ending OCSP Support in 2025 (seit 07.05.2025 nur noch CRL-URLs in Zertifikaten, OCSP-Responder am 06.08.2025 abgeschaltet)
🔭Certificate Transparency
Domaininhaber und Monitore (z. B. über crt.sh) durchsuchen die Logs nach Zertifikaten für ihre Namen. So fallen falsch ausgestellte Zertifikate auf – auch deshalb sollte man in internen Zertifikaten öffentlicher CAs keine geheimen Hostnamen verwenden: sie werden veröffentlicht.
📚 Quelle: RFC 6962 Certificate Transparency
📅Laufzeiten: immer kürzer
Maximale Laufzeit öffentlicher TLS-Zertifikate (CA/B Forum SC-081v3)
„Erneuern/Jahr“ bei Erneuerung nach ⅔ der Laufzeit. Kürzere Laufzeiten begrenzen den Schaden durch gestohlene Schlüssel und machen Sperrlisten weniger wichtig – setzen aber Automatisierung voraus. Ab 2029 müssen Domains alle 10 Tage neu validiert werden.
📚 Quelle: CA/B Forum Baseline Requirements §6.3.2, §4.2.1 · Ballot SC-081v3 (April 2025)
Let's Encrypt: von 90 auf 45 Tage
- 02.12.2025Ankündigung: Laufzeit sinkt schrittweise von 90 auf 45 Tage
- 13.05.2026Profil „tlsserver“ (Opt-in) stellt 45-Tage-Zertifikate aus
- 10.02.2027Standardprofil „classic“: 64 Tage, Autorisierung 10 Tage wiederverwendbar
- 16.02.2028Standardprofil „classic“: 45 Tage, Autorisierung 7 Stunden wiederverwendbar
Zusätzlich gibt es das Profil shortlived mit rund 6 Tagen Laufzeit. Solche kurzlebigen Zertifikate (≤ 7 Tage) brauchen laut Baseline Requirements keine Sperrinformationen. Empfohlen wird, die Erneuerung per ARI (RFC 9773) steuern zu lassen statt fester Intervalle.
📚 Quelle: letsencrypt.org, 02.12.2025 · Let's Encrypt Profiles
🔤PEM, DER, Base64
DER ist die binäre Kodierung der ASN.1-Struktur: jedes Element als Tag – Länge – Wert. Ein Zertifikat beginnt fast immer mit 30 82 xx xx = SEQUENCE mit 2-Byte-Länge.
PEM ist DER in Base64, 64 Zeichen pro Zeile, zwischen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- (RFC 7468). Deshalb beginnt jedes PEM-Zertifikat mit MII…: Base64 von 30 82.
fullchain.pem = Leaf + Intermediate(s) (für nginx ssl_certificate) · privkey.pem = privater Schlüssel (nur für root/nginx lesbar!) · .crt/.cer = PEM oder DER, die Endung verrät es nicht · .p12/.pfx = PKCS#12-Container mit Schlüssel und Kette, passwortgeschützt.