Zertifikatslebenszyklus und -sperrung

Jedes digitale Zertifikat durchläuft von der Erstellung bis zur Ausmusterung einen festgelegten Lebenszyklus. Die Phasen sind: Anforderung und Registrierung (Schlüsselpaar generieren, CSR erstellen), Ausstellung (CA validiert und signiert), Bereitstellung (Installation auf Server oder Gerät), Verwendung (aktiver Betriebszeitraum), Erneuerung (vor dem Ablauf) und Sperrung oder Ablauf (Ende der Gültigkeit). Die Verwaltung dieses Lebenszyklus in großem Maßstab – insbesondere in Unternehmen mit Tausenden von Zertifikaten – erfordert Automatisierung und Tools für das Certificate Lifecycle Management (CLM), da die manuelle Nachverfolgung unweigerlich zu abgelaufenen Zertifikaten und dadurch zu Ausfällen führt.

Der Lebenszyklus eines Zertifikats beginnt mit einer Certificate Signing Request (CSR). Der Antragsteller generiert ein Schlüsselpaar und erstellt anschließend eine CSR, die den öffentlichen Schlüssel, Subject-Informationen (CN, O, C) enthält und mit dem privaten Schlüssel signiert wird. Dadurch wird der Besitz des privaten Schlüssels nachgewiesen, ohne ihn offenzulegen. Die CSR wird an die CA übermittelt, die die Identität des Antragstellers validiert und das Zertifikat bei Genehmigung signiert. Der private Schlüssel verbleibt stets beim Antragsteller. Die CSR-Erstellung ist der entscheidende Schritt, in dem die Schlüsselstärke festgelegt wird – verwenden Sie mindestens 2048-Bit-RSA oder 256-Bit-ECC.

Zertifikate müssen erneuert werden, bevor ihr notAfter-Datum abläuft. Best Practice ist, den Erneuerungsprozess mindestens 30 Tage vor dem Ablauf zu beginnen (viele Unternehmen planen 60–90 Tage ein). Zur Erneuerung gehören typischerweise das Generieren einer neuen CSR und eines neuen privaten Schlüssels, die Übermittlung an die CA sowie das Ersetzen des alten Zertifikats und Schlüssels auf allen Servern, auf denen das Zertifikat bereitgestellt ist. Let's Encrypt automatisiert diesen Prozess mit dem ACME-Protokoll – das Tool certbot erneuert Zertifikate automatisch, sobald ihre Restlaufzeit weniger als 30 Tage beträgt. Abgelaufene Zertifikate führen zu Browserfehlern, die den Zugriff von Benutzern auf Dienste verhindern.

Die Zertifikatssperrung ist der Vorgang, ein Zertifikat vor dem geplanten Ablaufdatum ungültig zu machen. Gründe für eine Sperrung sind unter anderem: Der private Schlüssel wurde kompromittiert (am dringendsten – eine sofortige Sperrung ist erforderlich), das Zertifikat wurde fehlerhaft ausgestellt (falsche Domain, falsche Organisation), die Informationen zum Subject haben sich geändert (Unternehmen umbenannt, Mitarbeiter ausgeschieden) oder die CA selbst wurde kompromittiert. Die Sperrung ist entscheidend, da Browser und Systeme, die nicht wissen, dass ein Zertifikat gesperrt wurde, ihm weiterhin vertrauen. Dadurch kann ein Angreifer, der im Besitz des gestohlenen privaten Schlüssels ist, bis zum Ablauf des Zertifikats oder bis zur Bekanntgabe der Sperrung einen aktiven MITM-Angriff durchführen.

Eine Certificate Revocation List (CRL) ist eine von einer CA veröffentlichte signierte Liste, die die Seriennummern aller von ihr gesperrten und noch nicht abgelaufenen Zertifikate enthält. Clients laden die CRL herunter, speichern sie im Cache und prüfen, ob die Seriennummer eines präsentierten Zertifikats in der Liste vorkommt. CRLs haben erhebliche Einschränkungen: Sie können sehr groß sein (große CAs haben Millionen gesperrter Zertifikate), Clients speichern sie oft stunden- oder tagelang im Cache, wodurch Verzögerungen entstehen, und das Herunterladen der vollständigen CRL für jede Verbindung ist ineffizient. CRLs werden weiterhin verwendet, zunehmend jedoch durch OCSP ergänzt oder ersetzt.

OCSP (Online Certificate Status Protocol) ermöglicht die Überprüfung des Zertifikatssperrstatus in Echtzeit, ohne dass Clients vollständige CRLs herunterladen müssen. Der Client sendet eine Anfrage mit der Seriennummer des Zertifikats an den OCSP-Responder der CA. Der Responder antwortet mit einer signierten Antwort, die angibt, ob das Zertifikat good, revoked (mit Sperrdatum und Grund) oder unknown ist. OCSP ist schneller und aktueller als CRL, aber für jede TLS-Verbindung ist ein zusätzlicher HTTP-Roundtrip zum OCSP-Responder erforderlich, was die Latenz erhöht. OCSP-Antworten werden von der CA signiert, um Manipulationen zu verhindern.

OCSP-Stapling löst das Latenzproblem einer Echtzeit-OCSP-Prüfung. Statt dass der Client bei jedem TLS-Handshake den OCSP-Responder der CA abfragt, ruft der Server seine eigene OCSP-Antwort vorab bei der CA ab und „heftet“ sie an den TLS-Handshake an. Der Client erhält eine aktuelle, von der CA signierte OCSP-Antwort direkt vom Server – ein zusätzlicher Roundtrip ist nicht erforderlich. Der Server aktualisiert seine angeheftete OCSP-Antwort regelmäßig, typischerweise einmal pro Stunde. OCSP-Stapling beschleunigt den Verbindungsaufbau und reduziert die Last auf den OCSP-Respondern der CA, während die Prüfung auf Widerruf erhalten bleibt.

OCSP-Must-Staple ist eine X.509-Erweiterung, die Browsern mitteilt, dass der Server eine angeheftete OCSP-Antwort bereitstellen muss. Ohne diese Erweiterung führen Browser bei einem Fehlschlag der OCSP-Prüfung einen „Soft Fail“ durch – sie lassen die Verbindung dennoch zu, damit Ausfälle des OCSP-Responders nicht den gesamten TLS-Verkehr blockieren. Ein Angreifer kann dieses Verhalten ausnutzen, indem er die OCSP-Anfrage des Clients blockiert und so den Eindruck erweckt, das Zertifikat sei auch nach seinem Widerruf noch gültig. OCSP-Must-Staple verhindert dies, indem eine gültige angeheftete Antwort vorgeschrieben wird; fehlt sie, verweigert der Browser die Verbindung. Die Verbreitung bleibt aufgrund der aufwendigen Bereitstellung begrenzt.

Zertifikatswiderruf und Zertifikat-Pinning behandeln dasselbe Problem – das Vertrauen in betrügerische Zertifikate –, setzen aber an unterschiedlichen Punkten an. Widerruf (CRL/OCSP) ist ein reaktiver Mechanismus: Die CA macht ein Zertifikat ungültig, nachdem ein Problem festgestellt wurde. Pinning ist ein proaktiver Mechanismus: Die Anwendung akzeptiert ausschließlich ein vorab genehmigtes Zertifikat. Pinning bietet stärkere Garantien als der Widerruf, da es auch dann funktioniert, wenn die CA den Widerruf nicht zeitnah durchführt, führt jedoch zu einer weniger flexiblen Bereitstellung. Für die Security+-Prüfung sollten Sie beide Mechanismen kennen und verstehen, dass der Widerruf der standardmäßige PKI-Mechanismus ist, während Pinning eine optionale Maßnahme zur mehrschichtigen Verteidigung darstellt.

Wenn ein Zertifikat widerrufen wird, weist die CA einen Widerrufsgrundcode zu, der Clients und Administratoren hilft, den Grund zu verstehen. Zu den in RFC 5280 definierten gängigen Grundcodes gehören: keyCompromise (der private Schlüssel wurde kompromittiert), cACompromise (die ausstellende CA wurde kompromittiert), affiliationChanged (die Organisation des Antragstellers hat sich geändert), superseded (ein neues Zertifikat wurde als Ersatz ausgestellt), cessationOfOperation (die Domain ist nicht mehr aktiv) und privilegeWithdrawn (die Berechtigung wurde entzogen). Der Grundcode erscheint sowohl in CRL-Einträgen als auch in OCSP-Antworten und liefert Incident-Response-Teams, die Widerrufsereignisse untersuchen, zusätzlichen Kontext.

Das von Let's Encrypt verwendete Protokoll ACME (Automatic Certificate Management Environment) automatisiert den gesamten Zertifikatslebenszyklus. ACME-Clients wie certbot fordern Zertifikate automatisch an, erneuern und installieren sie, ohne dass ein manueller Eingriff erforderlich ist. Die CA verwendet Herausforderungen zur Domainvalidierung, um den Besitz der Domain zu bestätigen: Bei der HTTP-01-Herausforderung muss eine bestimmte Datei unter einer bekannten URL abgelegt werden; bei der DNS-01-Herausforderung muss ein DNS-TXT-Eintrag erstellt werden. ACME hat die Zertifikatsverwaltung grundlegend verändert – die 90-Tage-Zertifikate von Let's Encrypt ermöglichen inzwischen einen großen Teil des HTTPS-Datenverkehrs im Internet und werden vollständig automatisch erneuert.

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

In dieser Lektion haben Sie gelernt: Der Zertifikatslebenszyklus reicht von der CSR-Erstellung über Ausstellung und Bereitstellung bis zur Erneuerung oder zum Widerruf; CRL stellt stapelweise Widerrufslisten bereit, während OCSP den Status einzelner Zertifikate in Echtzeit liefert; OCSP-Stapling beseitigt die Latenz einer OCSP-Echtzeitprüfung; und ACME (Let's Encrypt) automatisiert den gesamten Erneuerungszyklus. Als Nächstes sehen wir uns PKI-Anwendungsfälle an.