CRL - Certificate Revocation List

Wenn eine Zertifizierungsstelle ihnen ein Zertifikat ausstellt, dann enthält das Zertifikat nicht nur ihren Namen bzw. den Servernamen, den Public Key, eine Gültigkeitsdauer und die Signatur der Zertifizierungsstelle, sondern auch ein oder mehrere Adressen für die "CRL". Diese Seite behandelt die "Rückrufliste" und deren praktischen Einsatz.

Unterschätzen Sie die Bedeutung der CRL nicht.
Wenn sie mit einer privaten CA arbeiten und z.B.: Zertifikate für "Direct Access" oder RDP-Gateways und RDP-Server verwenden, dann muss auch ein Client im Internet die CRL erreichen können. Ansonsten funktionieren MSTSC und Direct Access nicht sicher.

EMC and certificates with failed revocation checks in Exchange 2010
http://blogs.technet.com/b/exchange/archive/2010/07/26/455639.aspx

Certificate Revocation and Status Checking
http://technet.microsoft.com/en-us/library/bb457027.aspx

Warum gibt es die CRL ?

Wenn ein Zertifikat einmal ausgestellt ist, dann gilt es bis es abgelaufen ist. Das ist in den meisten Fällen richtig aber manchmal sollte ein Zertifikat nicht mehr verwendet werden, auch wenn es eigentlich noch gültig wäre. In den meisten Fällen hat das damit zu tun, dass der damit verbundene private Schlüssel veruntreut wurde. Aber es gibt noch andere Gründe

Sie sehen schon, dass die CRL aber nicht Sie als Zertifikatsinhaber oder die Zertifizierungsstelle betrifft, sondern die "andere Seite", d.h. der anonyme Websurfer im Internet oder ihr Kommunikationspartner für Mails. Da stellt sich die Frage, wie dieser denn nun darüber informiert wird, wenn ein Zertifikat nicht mehr gilt.

Damit ein externer fremder Client überhaupt prüfen kann, ob das Zertifikat zurück gezogen wurde, müssen gleich drei Dinge erfüllt sein

Schauen wir uns die Stellen genauer an

Wo steht die CRL ?

Jedes Zertifikat enthält nicht nur den Zertifikatinhaber, seinen öffentlichen Schlüssel und die Zertifizierungsstelle, sondern eben Auch die "Sperrlisten-Verteilpunkte". Diese definiert die Zertifizierungsstelle und kann von ihnen ganz einfach bei den Details des Zertifikats angezeigt werden. Hier sehen Sie einmal ein Zertifikat einer AD-Integrierten CA und ein Trustcenter-Zertifikat:

Die offizielle CA beschränkt sich natürlich auf das HTTP-Protokoll während die interne AD-integrierte CA durchaus auch einen LDAP-Pfad angeben kann. Die Clients können die Rückrufliste nämlich auch von einem DC vor Ost aus dem Active Directory auslesen.

CRL und Clients

Damit ein Client dies aber nutzt, muss er auch dazu konfiguriert sein. Am einfachsten erreichen Sie diese Einstellungen über die Internetoptionen des Internet Explorers.

Aber auch Programme wie Firefox haben ähnliche Einstellungen

Programme, die also nicht die Zertifikatfunktionen von Windows nutzen, haben die ähnlichen Funktionen.

Beachten Sie in dem Zuge auf jeden Fall auch die Hinweise zum Radius Server auf 802.1x

CRLs und Exchange

Auch Exchange prüft die CRLs und insbesondere auch das .NET Framework. Erstmals ist es mir bei Exchange 2010 SP1 RU3 aufgefallen, dass dieses "Problem" der langsamen Installation dem Administrator sogar explizit zur Kenntnis gebracht wird.

Unter der angegebenen URL http://go.microsoft.com/fwlink/?LinkId=158006 verweist am 11 Jul 2011 noch auf "How to Install the Latest Service Pack or Update Rollup for Exchange 2007" (http://technet.microsoft.com/en-us/library/ee221147(EXCHG.80).aspx), auf der das Wort "CRL" nicht mal vorkommt.

CRL und Smartcard

Wer sich an Windows mit einer Smartcard anmeldet, nutzt das darauf installierte Zertifikat. Der Anmeldeprozess (WINLOGON) prüft auch hier das Zertiifkat, ob es abgelaufen ist.

Das Verhalten kann über Registrierungsschlüssel kontrolliert werden. Um die Prüfungen z.B. abzuschalten, reichen folgende Einträge

Windows Registry Editor 5.0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc]
"UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors" = 1

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\Kerberos\Parameters]
"UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors" = 1

Ratsam ist es natürlich nicht, da zumindest beim internen Einsatz die CRL der eigenen CA erreichbar sein sollte.

CRL Erreichbarkeit, Performance und Konfiguration

Wenn nun der Client tatsächlich die CRL prüfen möchte und das Zertifikat eine entsprechende URL enthält, dann versucht der Client die URL zu erreichen. Dazu muss der Client natürlich die Berechtigung haben, über eine Firewall oder Proxy hinweg auch die CRL-URL zu erreichen. Vor allem müssen Sie als Zertifikataussteller natürlich auch die CRL unter der angegeben Adresse bereit stellen.

Es ist natürlich nicht sinnvoll, dass ein nach extern versendetes Zertifikat als CRL z.B. interne Servernamen enthält. Insofern sollten Sie die CRLs der Zertifizierungsstelle umgehend anpassen. Bei einer Windows CA geht das sogar per GUI auf den Eigenschaften der Zertifizierungsstelle.

Es bietet sich an, hier einen Alias wie z.B. "ca.firma.de" oder vielleicht auch den Webserver (z.B. www.firma.de/firmenca.crl) zu nutzen. Denn die CRL-Datei wird zwar auf der CA generiert und bereit gestellt, aber das heißt ja nicht, dass die Clients auch direkt auf den Webserver der CA zugreifen muss. Damit sind wir schon bei der Frage, welche URL hier denn sinnvoll ist. Schließlich muss sowohl ein Client aus dem internen LAN als auch ein Client im Internet die Adresse erreichen.

Veröffentlichungszeitpunkt

Die Rückruflisten werden von der Zertifizierungsstelle regelmäßig veröffentlicht. Eine CRL hat daher auch nur eine begrenzte Gültigkeit. Sie könne ja sich von einem existierenden Zertifikat (z.B. vom Homebanking-Zugang ihrer Hausbank) die Adresse der Rückrufliste anfordern und die Datei im Browser herunterladen und öffnen:

Die erste Seite enthält den Zeitpunkt, wann eine Aktualisierung ansteht und die zweite Seite die gesperrten Zertifikate. Die Intervalle können Sie über die Registrierung der Zertifikatsstelle anpassen: (Achtung: Wert für "caname" anpassen)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<caname>]
"CRLPeriod"="Weeks"
"CRLPeriodUnits"=dword:00000001
"CRLOverlapPeriod"="Hours"
"CRLOverlapUnits"=dword:00000000
"CRLDeltaPeriod"="Days"
"CRLDeltaPeriodUnits"=dword:00000001
"CRLDeltaOverlapPeriod"="Minutes"
"CRLDeltaOverlapUnits"=dword:00000000

Änderungen der Gültigkeit bei CRL (Default 1 Woche) und DeltaCRL (Default 1 Tag) wollen gut überlegt sein. Ich würde nicht ohne Grund von dem Microsoft Vorgaben und Standards abweichen.

Eleganter ist natürlich die Konfiguration über die offiziellen Tools

REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 30
certutil -setreg CA\CRLPeriod "Days"
REM
REM Disable Delta CRL publication
REM
certutil -setreg CA\CRLDeltaPeriodUnits 0

REM: Quelle: http://technet.microsoft.com/en-us/library/cc739715%28WS.10%29.aspx

CRLs mit einer privaten CA

Sicher werden Sie sich nun die Frage stellen, welche Daten sie bei der Installation der CA konfigurieren sollen. Glücklicherweise hat Microsoft hier ein sehr ausführliches Dokument bereit gestellt:

Dieses zitiere ich hier in Auszügen um eine Antwort auf die Frage der CRLs zu geben. Unter der Überschrift „CRL Best Practices“ finden Sie:

… It is a common mistake to not modify the default CRL distribution point of an isolated stand-alone CA. Because a root or intermediate CA is typically disconnected from the network, PKI-enabled clients cannot validate the issued certificates against the default CRL distribution point on the CA server. To make a CRL of an offline stand-alone CA publicly available, you must manually publish the CRL or utilize a custom exitmodule or script that publishes the CRL to a predefined location….

Etwas weiter folgt dann noch folgender Satz:

.. It is a best practice to publish a CRL that is available externally through an HTTP location so that users and applications that are outside of the organization may perform certificate validation. It is also a best practice to use paths and naming that do not reveal the internal network infrastructure to external entities…

Ehe Sie nun aber vorschnell eine CRL für das Stammzertifikat konfigurieren sollten sie noch ein Stück weiter lesen um folgendes zu finden:

A root CA certificate should have an empty CRL distribution point because the CRL distribution point is defined by the certificate issuer. Since the roots certificate issuer is the root CA, there is no value in including a CRL distribution point for the root CA. In addition, some applications may detect an invalid certificate chain if the root certificate has a CRL distribution point extension set.

Auch die RFCs enthalten entsprechende Informationen

According to RFC 3280 CRL checking should stop one level below the root.
Quelle: RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile http://www.ietf.org/rfc/rfc3280.txt

Eine CRL muss aber auch "veröffentlicht" werden und by Default läuft eine CRL alle 7 Tage ab. Das ist für eine "Offline-Root-CA" natürlich unbrauchbar, zumal diese ja eher wenige Zertifikate zurückruft. Wenn die RootCA aber auch Issuer-CA ist, dann ist das Rückrufen schon häufiger möglich. So eine RootCA ist dann natürlich auch "online" und kann (und muss) ihre CRL regelmäßig auch an den angegebenen Orten bereit stellen. Und das sollte sowohl von intern als auch aus dem Internet funktionieren. Besonders wenn Sie Dienste im Internet für ihre Clients anbieten, z.B. DirectAccess oder RDP-Gateways.

CRL-Url mit Alias
ich würde immer dazu raten, die CRL mit einem DNS-Alias unter einem eigenen Namen wie z.B. "crl.firma.de/certenroll/...." zu veröffentlichen und nicht mit einem anderen Namen zu kombinieren.

Für die Veröffentlichung gibt es eigentlich drei Optionen:

Bitte veröffentlichen Sie den IIS der Zertifizierungsstelle nicht per ReverseNAT über Port 80 im Internet.

Welche Lösung sie wählen, hängt stark von ihren Anforderungen, Sicherheitsüberlegungen und Firewalloptionen ab.

CRL/AIA/OCSP überprüfen

Ein Programm, mit welchem Sie die CRLs sehr einfach prüfen können ist CertUtil. Über den Parameter "-URL" weisen Sie CertUtil an, ein Zertifikat von einer Datei oder auch per HTTP-Download zu beziehen und zu prüfen. Wer mit der Kommandozeile nicht ganz sicher ist, gibt einfach eine beliebige HTTP-URL an:

certutil -URL http://www.msxfaq.net

Das Programm öffnet dann sowieso eine grafische Überfläche, in der Sie dann auch per Dialog eine CER-Datei auswählen können. CertUtil liest dann aus dem Zertifikat die verschiedenen Parameter aus und zeigt ihnen die Ergebnisse an. Hier am Beispiel einer fehlgeschlagenen Zertifikatsprüfung:

Das hier verwendete interne private Zertifikat ist aus dem Internet natürlich nicht per LDAP erreichbar und die veröffentlichte Sperrliste habe ich hier absichtlich "ablaufen "lassen.

CRL und RDP 7

Wenn sie nun glauben, dass sie ihre CA vielleicht nur intern einsetzen und daher keine Rücksicht auf Rückruflisten etc. nehmen müssen, dann schauen sie sich einfach mal folgendes Fenster an, welches ein Terminal Server Client von Windows 7 liefern kann:

Schaut man sich das Zertifikat aber genau an, dann ist das eigentlich in Ordnung.

 

Natürlich ist der LDAP-Pfad aus dem Internet so erst mal nicht erreichbar, aber die HTTP-Adresse ist natürlich erreichbar. Leider schert sich der Windows 7 RDP-Client anscheinend überhaupt nicht um die Einstellungen im Internet Explorer o.ä. und prüft immer die CRL und wenn diese nicht erreichbar ist, dann blockiert er den kompletten Zugang. Ich behelfe mir dann, dass ich mit RDP6 per MRemote auf den Server zugreife. Ähnliche Probleme könnten auf Sie mit DirectAccess und SSL-VPNs zukommen.

Insofern sollten CRLs immer von überall erreichbar sein, selbst wenn es sich um eine private CA handelt: Tipp: Pflegen Sie eine allgemeine URL wie z.B. crl.firmenname.de/pki/caname.crl, welche Sie einfach mit auf ihren öffentlichen Webserver mit ablegen. Der Abruf erfolgt ohne SSL-Verschlüsselung. Sie müssen allerdings dafür sorgen, dass die CRL-Datei immer wieder von der internen CA auf diesen Platz kopiert wird oder dass ihre Firewall (z.B. ISA-Server) einfach einen Zugriff auf diese URL zur internen CA gesichert durchreicht.

Manchmal scheitert es schon daran, dass das virtuelle Verzeichnis im IIS nicht für anonmyes "Lesen" freigegeben ist:

CRL und Webbrowser

Wird ein Webserver-Zertifikat zurück gerufen, sollten die Browser beim ersten Zugriff dies anzeigen. Im Gegensatz zu den sonstigen Warnungen, bei denen man dennoch weiter machen kann, blockieren Firefox und Internet Explorer den Zugriff komplett.


Firefox 3

Die gleiche Seite beim Zugriff mit dem Internet Explorer 8


Internet Explorer 8

Man kann also die Warnung nicht umgehen.

CRL Cache auf dem Client

Nun wäre es ja ungeschickt, bei jedem erhaltenen Zertifikat die CRL komplett neu zu laden. Daher "cachen" die Clients die CRL für die Zeit, die in der CRL als Gültigkeit hinterlegt wurde.

Die lokalen CRLs im Cache können über CertUtil auf dem Client angezeigt oder auch entfernt werden.

REM Anzeige der aktuell im Cache vorgehaltenen CRLs

certutil -urlcache crl
certutil -urlcache ocsp

REM Löschen der CRLs im lokalen Cache
certutil -urlcache crl delete
certutil -urlcache ocsp delete

Normalerweise sind diese Schritte nicht erforderlich. Nur wenn Sie z.B. intern mit der CRL "spielen" und z.B. die Zurückziehung eines Zertifikats auf einem Client umgehend testen wollen.

Etwas irritierend finde ich, dass in dem Cache auch andere "angesurfte URLs" protokolliert werden, die aber auch durch ein "Löschen" des Browserverlaufs etc. nicht entfernt werden

certutil -urlcache | findstr "Visited"

Zum Glück betrifft das aber nur die "eigene Session", d.h. auf einem Terminal Server kann ich über den Befehl wohl nicht ermitteln, wohin meine "Mit-"Arbeiter auf dem gleichen Server schauen.

Weitere Links

Keywords:CA CRL Zertifikat