Zertifikate: Laufzeiten und Widerrufe kontrollieren

Certificate Revocation Lists (CRLs)

Lange Zeit waren CRLs der de-facto-Standard bei PKIs. Eine Certification Authority (CA) erstellt dabei regelmäßig eine Liste von Zertifikatswiderrufen, jeweils mit Seriennummer, Widerrufszeitpunkt und Widerrufsgrund. Die Liste selbst hat ein Erstellungsdatum und ein Ablaufdatum und wird fast immer von der CA selbst signiert. Als Datei wird sie auf einem oder mehreren CRL Distribution Points (CDPs) veröffentlicht. Früher war meist LDAP dabei, mittlerweile oft nur noch HTTP. Bei Root CAs, die nur Sub-CA-Zertifikate ausstellen, ist eine Gültigkeit von 6-12 Monaten üblich. CRLs von Sub CAs sind typischerweise 1-2 Wochen gültig.

Dabei lädt ein System normalerweise nicht bei jeder Zertifikatsprüfung die aktuelle CRL herunter, sondern nutzt eine CRL aus dem Cache, die es bereits bei einer früheren Prüfung heruntergeladen hat. Eine neue CRL wird dann erst kurz vor Ablauf der CRL heruntergeladen. CRLs können nämlich sehr groß werden – die CRLs von öffentlichen CAs enthalten teils viele Zertifikate und können auf mehrere MB Größe anwachsen.

Das hat zusätzlich den Vorteil, dass bei Ausfall der CDPs die Zertifikate weiterhin mit der gecachten CRL auf Gültigkeit geprüft werden können. Aus guten Gründen werden nämlich Zertifikate, deren Gültigkeit nicht geprüft werden kann, als ungültig betrachtet, allerdings abhängig von der Einstellung. Angreifer könnten sonst gestohlene und widerrufene Zertifikate durch Störung der Verbindung zum CDP trotzdem verwenden.

Leider kommt deswegen ein Widerruf aber nur mit einer gewissen Trägheit sicher bei allen beteiligten Systemen an. Wird ein Zertifikat zurückgezogen, direkt nach Ausstellung einer zwei Wochen gültigen CRL, dann kann das Zertifikat noch zwei Wochen auf Systemen verwendet werden, die diese CRL nutzen.

Eine moderne Lösung, um die Verfügbarkeit des CDPs zu gewährleisten, ist der Einsatz eines Content Delivery Networks (CDNs), zum Beispiel auf Basis von Azure Blob Storage. Als Best Practice für Microsoft CAs richtet man dazu auf dem CA-System einen Scheduled Task ein, der beispielsweise täglich eine neue CRL ausstellt und in den Blob Storage hochlädt.

SCEPmans Architektur ist stateless, es verwendet für den üblichen Betrieb keine eigene Datenbank. Das hat viele Vorteile. Zum Beispiel sind Backups nicht nötig. Mehrere SCEPman-Instanzen laufen ohne weitere Konfiguration parallel; dadurch ist zum Beispiel auch ein automatisches Out-Scaling möglich, um Lastspitzen abzufangen. Die Zustandslosigkeit ist für eine Cloud-Anwendung also sehr gut, aber CRLs sind ohne Datenbank und damit ohne Speicherung der Liste widerrufener Zertifikate nicht möglich. SCEPman 2.4 generiert dynamisch CRLs bei jedem Zugriff auf den CDP, wobei die CRL nur manuell widerrufene Zertifikate enthält, so wie bei einer klassischen PKI.

Für eine Cloud-PKI gibt es glücklicherweise eine bessere Alternative:

Online Certificate Status Protocol (OCSP)

OCSP wurde 1999 für Hochsicherheitsanwendungen entworfen, bei denen die hohe Widerrufslatenz bei CRLs nicht akzeptabel war. Statt eine Liste aller widerrufenen Zertifikate vorzuhalten, kann ein System hierbei den Status eines konkreten Zertifikats von einem OCSP Responder abfragen. Um die Gültigkeit eines Zertifikats in Echtzeit zu prüfen, ist somit nur eine vergleichsweise kleine HTTP-Abfrage nötig. Der Antwortteil in der OCSP Response zum abgefragten Zertifikat hat dabei die gleiche ASN.1-Datenstruktur wie ein CRL-Eintrag, also Seriennummer, Widerrufszeitpunkt und Widerrufsgrund. Hierbei gibt es also keinen Unterschied zur CRL.

Die höhere Aktualität der Widerrufsinformationen hat einen Preis – fallen die OCSP-Responder einer CA aus, dann kann sofort kein Widerruf mehr geprüft werden, wodurch üblicherweise alle ausgestellten Zertifikate unverwendbar werden. Für OCSP-Responder sollte deswegen eine hohe Verfügbarkeit sichergestellt werden.

Bei den jeweiligen Implementierungen muss man allerdings genau hinschauen. Zum Beispiel Microsofts OCSP-Server nutzen als Widerrufsdatenbank eine CRL. Bei einer OCSP-Anfrage schaut der OCSP-Server also in der CRL nach, ob das Zertifikat dort eingetragen ist und antwortet entsprechend. Widerruft man ein Zertifikat an der CA, wird deswegen noch keine neue CRL erstellt und entsprechend wird der OCSP-Server genau wie die CRL behaupten, dass das Zertifikat nicht widerrufen sei. Einen Echtzeit-Widerruf erhält man also nicht automatisch, nur weil man OCSP einsetzt.

SCEPman nutzt OCSP, um die Zertifikatsgültigkeit zu steuern. Wird ein Zertifikat auf Widerruf geprüft, sucht SCEPman im Moment der OCSP-Anfrage das zugehörige Objekt – die Maschine oder den Nutzer – in Azure AD oder der JAMF-Datenbank und vergleicht, ob es den konfigurierten Anforderungen genügt. Wenn man beispielsweise ein Computerobjekt im AAD deaktiviert oder löscht, wird damit sofort auch dessen Zertifikat ungültig. So konnten wir erreichen, dass man Zertifikate ohne Zeitverzug widerrufen kann und sogar ohne die bei herkömmlichen PKIen erforderliche umständliche Zertifikatsverwaltung.

Wie im letzten Abschnitt beschrieben, ist SCEPman zustandslos. Das haben wir erreicht, indem SCEPman AAD und JAMF als Basis für den Zertifikatsstatus nutzt und deswegen keine eigene Datenbank benötigt. Daher lässt sich SCEPman leicht hochverfügbar realisieren, auch geo-redundant. Microsoft garantiert für seine Azure App Services eine hohe Verfügbarkeit, so dass selbst mit einer Instanz oft eher das VPN-Gateway oder der WiFi-NAC ausfällt als der OCSP-Responder. Während die aufwändige Hochverfügbarkeit mit on-premises-Komponenten den Einsatz eines OCSP-Responders verhindern kann, ist sie bei SCEPman kein Problem.

Manche Zertifikate sind jedoch auch bei SCEPman nicht mit einem Verzeichnisobjekt verknüpft oder man möchte sie unabhängig vom Zustand des Verzeichnisobjekts widerrufen. Beispiele wären die Zertifikatsverteilung über Mosyle, soweit man die Zertifikate nicht trotzdem an AAD-Objekte knüpft, oder Server-Zertifikate. Für diese Fälle nutzt SCEPman dann doch eine Datenbank, nämlich einen Azure Storage Account mit Table Storage. SCEPman benötigt die Datenbank für OCSP aber nur lesend und Table Storage ist nicht-relational und selbst in der günstigsten SKU schon redundant, so dass Replikationen entfallen und Backups nicht nötig sind. SCEPman nutzt die Datenbank parallel zum etwaigen MDM-Verzeichnis als Quelle von Widerrufsinformationen. Falls erforderlich kann SCEPman dennoch ausgestellte Zertifikate in der Datenbank speichern, um einen einfachen manuellen Widerruf zu ermöglichen als Ergänzung zum automatischen Widerruf.

Das folgende Diagram zeigt, wie OCSP bei SCEPman funktioniert bei einer Installation auf drei verteilten App-Service-Instanzen:

Hierbei möchte ein Client (das muss kein Endnutzer-Gerät sein, sondern zum Beispiel ein RADIUS-Server wie RADIUS-as-a-Service) die Gültigkeit eines Zertifikats prüfen. Er nutzt den DNS-basierten Azure Traffic Manager, um eine funktionsfähige und nahe SCEPman-Instanz zu finden und ihr einen OCSP-Request zu schicken. Die gewählte SCEPman-Instanz fragt daraufhin parallel den Azure-Storage-Account und Intune ab, um zu sehen, ob das mit dem Zertifikat verknüpfte Geräteobjekt existiert und in einem gültigen Zustand ist. Die OCSP-Response spiegelt die Ergebnisse wieder. Eine einzige Azure-Storage-Instanz reicht aus, weil Azure Storage immer redundant ist, der Grad der Redundanz hängt von der gewählten SKU ab. Azure Key Vault ist ebenfalls immer redundant. MEM/Intune ist als Microsoft Cloud-Service ohnehin redundant ausgelegt. Die SCEPman-Instanzen kommunizieren nicht mit einander und Clients bauen keine Sessions mit SCEPman-Instanzen für ihre OCSP-Requests auf, so dass keine Cookies oder ähnliches beteiligt sind. SCEPman-Instanz können deswegen wie benötigt einfach hinzugefügt und entfernt werden.

Short Lifetime Certificates

In manchen Anwendungen ist es von Vorteil, wenn gar keine Widerrufsprüfung vor jeder Zertifikatsverwendung notwendig ist. Ein Beispiel sind Systeme, die völlig ohne Netzwerkverbindung – und damit ohne Kontakt zu CDP oder OCSP-Responder, miteinander kommunizieren sollen. Oder eine Gültigkeitsprüfung ist so aufwändig, dass sie nur zum Zeitpunkt der Ausstellung unter Beteiligung des Zertifikatsinhabers stattfinden kann, nicht aber durch die CA. Trotzdem können solche Zertifikate kompromittiert werden und die PKI muss den Schaden durch die Kompromittierung eingrenzen können, indem das Zertifikat seine Gültigkeit wieder verliert.

In solchen Fällen bieten sich Short Lifetime Certificates an, also Zertifikate, die von vorneherein eine vergleichsweise kurze Gültigkeitsdauer haben, nur Tage oder Stunden. Ein Widerruf ist bei solchen Zertifikaten nicht nötig, da ein kompromittiertes Zertifikat ohnehin nach kurzer Zeit ungültig wird – oft sogar schneller als bei Einsatz einer CRL.

Durch die einfachere Architektur ergeben sich weitere Vorteile: Der CDP oder OCSP-Responder muss nicht geplant und betrieben werden. Bei der Zertifikatsnutzung ist kein Netzwerkverkehr notwendig. Die Zertifikate müssen wegen ihres geringen Werts nicht verwaltet werden.

Ein Fallstrick ist jedoch, dass die Zertifikate besser auch gar nicht verwaltet werden sollten. Durch die kurze Gültigkeit stellt eine CA deutlich mehr solcher Zertifikate aus als bei Einsatz langlebiger Zertifikate. Werden Short Lifetime Certificates trotzdem in einer Datenbank gespeichert, so wächst diese schnell auf sonst unübliche Größen an, für die sie womöglich nicht ausgelegt ist. Die Microsoft CA bietet deswegen pro Zertifikatsvorlage an, diese Zertifikate gar nicht erst in der Datenbank zu speichern. Dazu muss die Kompatibilitätsstufe auf mindestens Windows Server 2008 R2 gestellt werden, was nicht die Voreinstellung ist.

Für WiFi- und VPN-Client-Zertifikate sind Short Lifetime Certificates nicht optimal. Der Aufbau der Netzwerkverbindung benötigt ein gültiges Zertifikat; aber um ein neues Zertifikat zu erhalten, benötigt der Client eine Netzwerkverbindung. Das ist dann kein Problem, wenn die Zertifikate rechtzeitig vor Ablauf erneuert werden. Dafür sorgen Microsoft Intune oder JAMF in Zusammenspiel mit SCEPman automatisch, auch mit einer traditionellen Microsoft CA und Auto-Enrollment ist eine Erneuerung ohne Nutzerinteraktion möglich. Bei Short Lifetime Certificates geraten Maschinen spätestens dann in den Teufelskreis aus fehlender Netzwerkverbindung und fehlendem Zertifikat, wenn ihre Nutzer eine Woche im Urlaub sind und deren Geräte in dieser Zeit ausgeschaltet sind.

Bei TLS-Zertifikaten geht Let’s Encrypt bereits in die Richtung kürzerer Zertifikatslaufzeiten. Durch die automatisierte Zertifikatsausstellung und weil Server nur dann Zertifikate brauchen, während sie laufen, ist das für Server auch kein Problem.

SCEPman empfiehlt Short Lifetime Certificates daher nur für Server-Zertifikate. Ab Version 1.7 kann die Zertifikatslaufzeit pro Endpunkt konfiguriert werden, so dass man OCSP für Clientzertifikate nutzen kann, während man beispielsweise automatisch beantragte Domain-Controller-Zertifikate mit einer kürzeren Laufzeit versieht. Kurze Laufzeiten sind außerdem empfehlenswert, wenn man zusätzliche Systeme über den statischen Endpunkt mit Zertifikaten versorgt.

Schlussfolgerung

Jede Widerrufsmethode hat eigene Vor- und Nachteile, womit die optimale Wahl vom konkreten Einsatz abhängt. Für eine traditionelle on-premises Infrastruktur-PKI sind CRLs meist die beste Wahl, weil sie einfach umzusetzen sind. Bei einer modernen Cloud-PKI wie SCEPman ist OCSP besser, da es Widerruf in Echtzeit ermöglicht und eine cloud-freundliche zustandslose Umsetzung. Short Lifetime Certificates haben für manche Anwendungen ihre Daseinsberechtigung und können mit CRLs oder OCSP in einer einzelnen PKI gemischt werden. Die Wahl der Methode hängt dann vom Zertifikatstyp ab. Die folgende Tabelle fasst einige der wichtigsten Argumente für die einzelnen Techniken zusammen:

Für Öffentliche Zertifizierungsstellen verlangen Apple und Mozilla CRLs, da OCSP in diesem Fall ein Datenschutz-Problem verursacht: Jede OCSP-Anfrage zeigt dem OCSP-Responder, welche Domain von welcher IP-Adresse besucht wurde. Für interne CAs wie SCEPman ist das kein Problem, da die Organisation, die SCEPman nutzt, einerseits den OCSP-Responder betreibt, aber auch die Clients verwaltet, auf die SCEPman Zertifikate verteilt. Deswegen erlangt sie über den OCSP-Responder keine zusätzlichen Informationen. Aaron Gable von Let’s Encrypt hat dies zusammengefasst und erklärt wie Let’s Encrypt damit umgeht.

Sonderfall AAD CBA

Ein Sonderfall ist die zertifikatsbasierte Authentifizierung für Azure AD, die vor Kurzem den Preview-Status verlassen hat. Microsoft hat bei der Umsetzung offenbar nicht auf verbreitete Krypto-Bibliotheken zurückgegriffen, die ausnahmslos sowohl OCSP als auch CRLs unterstützen, sondern die kryptografischen Routinen selbst geschrieben und dabei nur CRL-Unterstützung umgesetzt. Dabei wird auch nicht der CDP aus dem Zertifikat ausgelesen, sondern separat im Azure-Portal konfiguriert. Hierfür ergeben sich daher besondere Anforderungen.

Dies ist ein Anwendungsfall, um SCEPmans CDP im AAD zu hinterlegen. Wenn das AAD einen Zertifikatswiderruf prüft, wird es die CRL nutzen. Andere Systeme verwenden den OCSP-Responder mit seinen aktuelleren Widerrufsinformationen und besserer Performance.