Ein Zertifikat ist ausgestellt, der Server läuft – und dann wird der Private Key gestohlen. Das Zertifikat ist noch Monate gültig. Was jetzt? Dieser Block erklärt euch, wie Zertifikate widerrufen werden und wie Browser und Clients davon erfahren.

Nach diesem Block könnt ihr:

• erklären, warum Zertifikate widerrufen werden müssen und welche Gründe es gibt
• CRL und OCSP beschreiben und ihre Vor-/Nachteile gegenüberstellen
• OCSP Stapling erklären und wissen, warum es Datenschutzprobleme löst
• mit OpenSSL CRL-URLs und OCSP-Status eines Zertifikats abfragen

Das Problem: Was passiert, wenn ein Zertifikat kompromittiert wird?

Ein Zertifikat hat eine Gültigkeitsdauer von typischerweise 90 Tagen (Let’s Encrypt) bis 1–2 Jahren. Aber was passiert, wenn der zugehörige Private Key gestohlen wird, bevor das Zertifikat abläuft?

Szenario:
  1. Januar:  CA stellt Zertifikat für bank.de aus (gültig bis 31. Dezember)
  15. März:   Angreifer stiehlt den Private Key von bank.de
  16. März:   bank.de meldet der CA: "Unser Key ist kompromittiert!"

  → Das Zertifikat ist bis 31. Dezember formal gültig.
  → Ohne Widerruf würden Browser es weiterhin akzeptieren.
  → Der Angreifer könnte MITM-Angriffe mit dem gestohlenen Key durchführen.

Die Lösung: Die CA muss das Zertifikat widerrufen und alle Clients müssen davon erfahren.

CRL – Certificate Revocation List

Eine CRL ist eine von der CA signierte Liste aller widerrufenen Zertifikate. Sie enthält die Seriennummern der Zertifikate, die vor ihrem Ablaufdatum für ungültig erklärt wurden.

CRL-Inhalt (vereinfacht):
  Ausgestellt von: TechWerk Root CA
  Gültig bis: 2024-04-01
  Widerrufene Zertifikate:
    Seriennummer 0x1A3F  – widerrufen am 2024-03-16, Grund: keyCompromise
    Seriennummer 0x2B8C  – widerrufen am 2024-03-10, Grund: cessationOfOperation
    Seriennummer 0x3D12  – widerrufen am 2024-02-28, Grund: affiliationChanged
  Signatur der CA: [...]

Ablauf der CRL-Prüfung:

Client                           CA-Server (CRL Distribution Point)
  │                                             │
  │  Ruft Webseite auf, bekommt Zertifikat      │
  │                                             │
  │  CRL-URL aus Zertifikat lesen               │
  │  (Feld: CRL Distribution Points)            │
  │                                             │
  │──── HTTP GET /crl/root-ca.crl ─────────────►│
  │◄─── CRL-Datei (signiert) ───────────────────│
  │                                             │
  │  Signatur der CRL prüfen                    │
  │  Seriennummer des Zertifikats in CRL suchen │
  │  → Nicht gefunden: gültig                   │
  │  → Gefunden: widerrufen → Verbindung ablehnen

Nachteile der CRL:

• CRL-Datei kann groß werden (bei großen CAs tausende Einträge)
• CRL hat eine Gültigkeitsdauer (oft 1–7 Tage) → Widerruf wird nicht sofort überall bekannt
• Client muss die CRL-Datei herunterladen → Latenz, Privatsphäre (CA sieht, welche Zertifikate geprüft werden)
• Wenn der CRL-Server nicht erreichbar ist: je nach Konfiguration wird Zertifikat als gültig angesehen (Fail-Open)

Das ist der entscheidende Schwachpunkt: Eine CRL ist immer ein Snapshot der Vergangenheit. Zwischen dem Widerruf und der nächsten CRL-Aktualisierung liegt ein Fenster – in dem ein kompromittiertes Zertifikat noch als gültig gilt. Genau das löst OCSP.

# CRL-URL aus einem Zertifikat anzeigen
openssl x509 -in server.crt -text -noout | grep -A4 "CRL Distribution"

# CRL herunterladen und anzeigen
curl -s http://crl.example.com/root-ca.crl -o ca.crl
openssl crl -in ca.crl -inform DER -text -noout

# Prüfen ob ein Zertifikat in einer CRL widerrufen wurde
openssl crl -in ca.crl -inform DER -noout -text | grep -A2 "Serial Number"
# Oder direkt prüfen:
openssl verify -crl_check -CRLfile ca.crl -CAfile ca.crt server.crt

OCSP – Online Certificate Status Protocol

OCSP löst die CRL-Nachteile durch Echtzeitabfragen. Statt eine große Liste herunterzuladen, fragt der Client für ein einzelnes Zertifikat direkt beim OCSP-Responder der CA an.

Client                                OCSP-Responder (der CA)
  │                                            │
  │  Bekommt Zertifikat (Seriennummer: 0x1A3F) │
  │                                            │
  │──── OCSP Request (Seriennummer 0x1A3F) ───►│
  │                                            │  CA prüft Status
  │◄─── OCSP Response (signiert) ──────────────│
  │     Status: "good" / "revoked" / "unknown" │
  │     Zeitstempel der Antwort                │

OCSP-Response-Status:

• good: Zertifikat ist gültig und nicht widerrufen
• revoked: Zertifikat ist widerrufen – mit Zeitpunkt und Grund
• unknown: OCSP-Responder kennt das Zertifikat nicht

# OCSP-URL aus einem Zertifikat anzeigen
openssl x509 -in server.crt -text -noout | grep -A2 "OCSP"

# OCSP-Abfrage manuell durchführen
openssl ocsp \
    -issuer ca.crt \
    -cert server.crt \
    -url http://ocsp.example.com \
    -resp_text

# OCSP-Anfrage gegen einen echten Server
openssl s_client -connect google.com:443 -status </dev/null 2>/dev/null | \
    grep -A10 "OCSP Response"

Nachteil Standard-OCSP:

Datenschutzproblem – bei jeder HTTPS-Verbindung fragt der Browser bei der CA nach. Die CA kann damit nachvollziehen, welche Websites ein Nutzer besucht. Das ist kein theoretisches Risiko: Eine CA, die Millionen von Anfragen bekommt, hat ein detailliertes Bild des Browserverhaltens ihrer Nutzer. OCSP Stapling löst das.

OCSP Stapling

OCSP Stapling löst das Datenschutz- und Performance-Problem: Statt dass der Client die CA fragt, holt sich der Webserver regelmäßig eine OCSP-Antwort von der CA und “heftet” (stapelt) sie an die TLS-Verbindung an.

Ohne Stapling:
  Client ──► Webserver (Zertifikat)
  Client ──► CA (OCSP-Anfrage)     ← Datenschutzproblem, Latenz

Mit Stapling:
  Webserver ──► CA (OCSP-Anfrage)  ← passiert im Voraus, periodisch
  Client    ──► Webserver (Zertifikat + signierte OCSP-Antwort)
               → Client vertraut der OCSP-Antwort, weil sie von der CA signiert ist
               → Keine direkte Kommunikation des Clients mit der CA nötig

Genau deshalb ist OCSP Stapling heute der De-facto-Standard: Es löst gleichzeitig das Datenschutzproblem (die CA sieht nicht, welche Seiten ihr besucht) und das Performance-Problem (kein zusätzlicher Roundtrip für den Client). Der Webserver holt alle paar Stunden eine frische OCSP-Antwort von der CA und heftet sie an den TLS-Handshake – der Client bekommt den Widerrufsstatus quasi gratis mitgeliefert, ohne selbst die CA kontaktieren zu müssen. Ist die geheftete Antwort allerdings abgelaufen oder fehlt sie ganz, kann der Client auf eine direkte OCSP-Abfrage zurückfallen – oder das Zertifikat je nach Browser-Policy trotzdem akzeptieren (das ist das bekannte „Soft-Fail”-Problem).

OCSP Stapling in Apache aktivieren:

# In der Apache VirtualHost-Konfiguration:
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

# OCSP Stapling prüfen
openssl s_client -connect example.com:443 -status </dev/null 2>/dev/null | \
    grep -A20 "OCSP Response Data"
# Wenn "OCSP Response Status: successful" erscheint, ist Stapling aktiv.

Vergleich CRL vs. OCSP vs. OCSP Stapling

Widerrufsgründe (RFC 5280)

Merke: Widerruf ist nur so gut wie die Prüfung durch den Client. Viele Browser haben in der Vergangenheit OCSP-Fehler ignoriert (Fail-Open). Deshalb setzt die Industrie zunehmend auf kurze Zertifikatslebenszeiten (Let’s Encrypt: 90 Tage) als ergänzende Strategie – wenn Zertifikate kurz gültig sind, ist der Schaden bei einem kompromittierten Schlüssel begrenzt.

Certificate Transparency (CT)

Problem: CRL und OCSP helfen beim Widerruf – aber was, wenn eine CA versehentlich oder böswillig ein Zertifikat für eine Domain ausstellt, die ihr gar nicht gehört? Ohne Wissen über die Ausstellung kann der Domaininhaber keinen Widerruf beantragen. Das fehlerhafte Zertifikat bleibt unentdeckt.

Lösung: Seit 2018 müssen alle öffentlich vertrauenswürdigen Zertifikate in öffentliche CT-Logs eingetragen werden. Chrome lehnt Zertifikate ohne CT-Eintrag ab.

Wie CT funktioniert:

CA stellt Zertifikat aus
  │
  ├──► CT-Log A (unabhängig betrieben) ──► gibt SCT zurück (Signed Certificate Timestamp)
  ├──► CT-Log B (unabhängig betrieben) ──► gibt SCT zurück
  │
  ▼
Zertifikat enthält SCTs als Nachweis der Eintragung

Browser prüft beim TLS-Handshake:
  → Hat das Zertifikat mindestens zwei gültige SCTs? → Ja: akzeptieren → Nein: ablehnen

Praktischer Nutzen: Über die öffentliche Suchmaschine crt.sh könnt ihr alle CT-Logs durchsuchen. Gebt eure Domain ein und seht sofort, welche Zertifikate dafür ausgestellt wurden – auch solche, die ihr nicht beantragt habt.

Merke: CT verhindert nicht die Ausstellung falscher Zertifikate – aber es macht sie sichtbar. Zusammen mit CRL/OCSP ergibt sich ein vollständiges Bild: CT erkennt fehlerhafte Ausstellung, CRL/OCSP widerruft sie.

Zusammenfassung

• Zertifikate können vor Ablauf widerrufen werden – z.B. bei gestohlenen Private Keys
• CRL ist eine herunterladbare Liste widerrufener Zertifikate – einfach, aber veraltet (Stunden bis Tage Verzögerung)
• OCSP fragt den Status einzelner Zertifikate in Echtzeit ab – schneller, aber mit Datenschutzproblem
• OCSP Stapling löst beides: Der Server holt die OCSP-Antwort vorab und liefert sie beim TLS-Handshake mit
• Kurze Zertifikatslebenszeiten (Let’s Encrypt: 90 Tage) sind eine ergänzende Strategie

Selbsttest

1. Der Private Key eines Webservers wird gestohlen. Das Zertifikat ist noch 10 Monate gültig. Was müsst ihr sofort tun, und warum reicht es nicht, auf den Ablauf zu warten?
2. Was ist das Datenschutzproblem bei Standard-OCSP, und wie löst OCSP Stapling es?
3. Erklärt, was „Fail-Open” bei der Widerrufsprüfung bedeutet und warum das ein Sicherheitsrisiko ist.

Wie geht es weiter?

Zertifikate, PKI, Widerruf – alle Puzzleteile sind da. Block 08 setzt sie zusammen: TLS ist das Protokoll, das asymmetrischen Schlüsselaustausch, symmetrische Verschlüsselung und Zertifikate in einem Handshake vereint. Wer TLS versteht, versteht HTTPS.