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

Creating a Certificate Revocation List Distribution Point für Your Internal Certification Authority
http://blogs.technet.com/b/nexthop/archive/2012/12/17/creating-a-certificate-revocation-list-distribution-point-for-your-internal-certification-authority.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

  • Zertifikat/PrivateKey kompromittiert
    Es kann durchaus sein, dass ein Webserver bzw. das Zertifikat darauf samt privatem Key abhanden kommt und nun von jemand anderem vielleicht missbraucht werden kann. ähnliches gilt z.B. für CodeSigning-Zertifikate. Microsoft signiert z.B. alle Windows Updates. Würde es jemandem gelingen diese Schlüsselpaarung zu kopieren oder zu entwenden, könnte derjenige auch Programme erstellen, verteilen und sich als "Microsoft" ausgeben.
  • Mitarbeiter scheidet aus (S/MIME)
    Wenn ein Postfach entfernt wird, sollte auch das dazu gehörige Zertifikat als unkenntlich markiert werden, damit alle Absender, die das Zertifikat vielleicht noch haben, dieses nicht mehr weiter nutzen.
  • Maildomäne ändert sich
    Es wäre nicht das erst mal, dass eine Firma gekauft oder umfirmiert wird uns als erster Schritt alle unter dem neuen Namen auftreten müssen. Die bestehenden Zertifikate sind zwar nicht ungültig aber ein aktives Zurückziehen zwingt auch die Geschäftspartner dazu, den neuen Namen zu nutzen
  • Private Key verloren
    Sicher häufigster Fall ist die Situation, dass ein PC defekt wird und wenn der private Schlüssel nicht über "Roaming Profiles" oder ein System State Backup des Clients gesichert ist, dann kommt der Anwender auch mit einem neuen PC nicht mehr an die alten verschlüsselten Mails ran. Schlimmer ist aber vielleicht, dass er zukünftig auch noch weiter verschlüsselte Mails dieses Zertifikats bekommt und dann dem Absender ein "Sorry, do it again" zurufen muss. Hier lindert ein Rückruf des Zertifikats die Blamage ein wenig.
  • Ausstellende CA kompromittiert
    Ganz böse wird es, wenn die Zertifizierungsstelle selbst kompromittiert wird. Wenn die CA nur eine "Subordinate" war, muss der Administrator der übergeordneten CA einfach die SubCA zurückziehen und alle davon abgeleiteten Zertifikate sind auch unbrauchbar.

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.

  • Gültige CRL im Zertifikat
    Im Zertifikat muss der Client die Adresse der CRL finden:
  • CRL muss erreichbar sein
    d.h. die angegeben URL muss zum einen im Internet erreichbar sein und der Client muss seinerseits z.B. über einen Proxy auch dort hin kommen. Das ist z.B. mit Authenticode auf Servern nicht immer einfach
  • Client muss CRL prüfen und warnen
    Zuletzt muss der Client natürlich noch so konfiguriert sein, dass er die CRL beachtet, abruft und den Anwender entsprechend warnt. Ist ein Zertifikat zurückgezogen, dann sollte er deutlich Warnen. Ist nur die CRL nicht erreichbar, kann er darüber informieren.

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. Aber Achtung:

Domain credential is required to access the LDAP CDP. In order that the workgroup client computer can download the CRL, you need to publish the CRL to an HTTP location.

Das Zertifikat einer "RootCA" (Stammzertifikate) haben aber keine CRL, da es ja darüber keine CA gibt, die die Root-Zertifikate signiert hat. Um ein Root-Zertifikat ungültig zu machen, muss man diese auf den Clients entfernen oder in die lokale Sperrliste aufnehmen.

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

CRL-Caching

Um die Zugriff auf CRLs zu beschränken, werden Zugriffe im Cache gehalten. "Eigentlich" funktioniert das ganz gut aber folgende Befehle löschen den Cache

certutil -urlcache crl delete
certutil -urlcache ocsp delete

So können Sie speziell nach einer Änderung der Firewall verifizieren, ob die CRLs wieder abgerufen werden können.

CRL 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 für Exchange 2007" (http://technet.microsoft.com/en-us/library/ee221147(EXCHG.80).aspx), auf der das Wort "CRL" nicht mal vorkommt.

CRL und Lync

Auch Lync Server nutzen natürlich Zertifikate, damit die Clients sich per SIP/TLS anmelden oder die Webservices ansprechen können. Auch hier prüft der Client die CRL. Zudem stellt der Lync Server dem Anwender ein Zertifikat aus, welches er auf dem Client installiert und in der Folge zur Anmeldung nutzen kann. Dieses Zertifikat hat keine CRL, da es nur ein "Selbstzertifikat" ist und in der Lync Datenbank eingetragen ist.

Einen Fall gibt es aber doch, wo ein fehlender CDP zu Problemen führt. Der Lync Communicator verbindet sich per TLS mit dem Lync Server und erwartet auch hier, dass das Zertifikat einen CDP enthält und dieser erreichbar ist. Wenn die Zertifikate von einer Internen CA ausgestellt werden, dann ist es aber auch möglich, dass die CDP gar nicht vorhanden ist. Das mag der Lync Client gar nicht. Im Log findet sich dann z.B. der Fehler "0x80ee00ca".

Auch sollte die CRL auf eine gültige URL verweisen, die auch erreichbar ist. Jeff Schertz hat das Problem auch bei der Windows Store App nachvollziehen können.

CRL und SharePoint

Auch SharePoint nutzt intensiv Zertifikate. Diese kommen nicht nur auf dem IIS zum Einsatz, mit dem sich die Anwender verbinden sondern auch zwischen den verschiedenen SharePoint-Rollen werden Kommunikationen per Zertifikat gesichert. Wenn hier dann der anfragende Prozess das bereitgestellte Zertifikat überprüfen will und das nicht "sofort" möglich ist, werden auch hier Dienste langsamer oder instabil. Die Ursache ist hier nicht immer genau zu ermitteln. Natürlich hilft auch eine Fehlersuche mit NetMon 3, Wireshark und natürlich CAPI2-Debugging. Neben der Kommunikation zwischen den Diensten sind es natürlich oft auch die digital signierten DLLs, die verzögert instanziert werden, wenn die CRL nicht erreichbar ist.

In Testumgebungen hat man aber nicht immer die Möglichkeit diese Infrastrukturdienste entsprechend zuverlässig vorzuhalten. Dann kann man auch für SharePoint diese Prüfungen abschalten. Das sind aber keine Einstellungen "pro SharePoint" sondern für das von SharePoint genutzte .NET Framework.

CRL und Smartcard

Wer sich an Windows mit einer Smartcard anmeldet, nutzt das darauf installierte Zertifikat. Der Anmeldeprozess (WINLOGON) prüft auch hier das Zertifikat, 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 für 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. Direct Access 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:

  • CRL auf einen externen Webserver ablegen
    Die meisten Firmen, die eine CRL auch extern bereit stellen müssen, laden diese nach jeder Generierung oder regelmäßig auf einen extern erreichbaren Webserver, Das kann sogar einfach ein unterverzeichnis auf dem offiziellen Webserver sein. Die CRL von Net at Work finden Sie auch auf www.msxfaq.de/certenroll, wobei diese URL so nie verwendet wird. Dazu gibt es extra "crl.msxfaq.de". Allerdings müssen Sie schon überwachen, dass eine neue CRL zeitnah und fehlerfrei auf das Ziel hochgeladen wird. Ob Sie dazu ein XCOPY, ein VBScript oder eines der vielen Filesync-Tools wie z.B. Syncback einsetzen, überlasse ich ihnen.
  • CRL auf der CA über Reverse Proxy veröffentlichen
    Eine andere Option ist die Veröffentlichung des "Certenroll"-Verzeichnisses, welches durch den IIS auf der Zertifizierungsstelle intern schon veröffentlicht wird, über einen Reverse Proxy. Das kann ein ISA oder TMG sein, das kann aber auch ein Apache als Reverse Proxy sein. Sie ersparen sich so die "Kopieraktion", aber auf der anderen Seite machen Sie ihre CA intern zumindest auf einer URL anonym erreichbar.

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

Welche Lösung sie wählen, hängt stark von ihren Anforderungen, Sicherheitsüberlegungen und Firewall-Optionen 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.

Sie können auch ein lokales Zertifikat prüfen, welches nur als CER-Datei vorliegt:

C:\>certutil -verify  "usercert.cer"

Aussteller:
    CN=msxfaqROOTCA
    DC=msxfaq
    DC=de
  Namenshash (sha1): d7b13d1474ef3a5dd9f637d9e9c5516cc30efa79
  Namenshash (md5): fcae383b0b49161bd9cdd8baccb96e55
Antragsteller:
    E=frank.carius@msxfaq.de
    CN=Carius, Frank
    OU=Technik
    DC=msxfaq
    DC=de
  Namenshash (sha1): d60f22e57739f17790f68f06d36c4a9f7a4c6abb
  Namenshash (md5): dae04270637c159df9091bf9fe72b437
Zertifikatseriennummer: 188328510000000000bd

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_TIME_VALID (0x1)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_NOT_TIME_VALID (0x1)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=2 dwErrorStatus=1000041
  Issuer: CN=msxfaqROOTCA, DC=msxfaq, DC=de
  NotBefore: 27.07.2008 01:40
  NotAfter: 27.07.2009 01:40
  Subject: E=frank.carius@msxfaq.de, CN="Carius, Frank", OU=Technik, OU=Abteilung, DC=msxfaq, DC=de
  Serial: 188328510000000000bd
  SubjectAltName: Anderer Name:Prinzipalname=fcarius@msxfaq.de, RFC822-Name=frank.carius@msxfaq.de
  Template: User
  Cert: 193280f838b4e7e9e4c729bb279264171c1c7262
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwErrorStatus = CERT_TRUST_IS_NOT_TIME_VALID (0x1)
  Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
  Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
  Application[0] = 1.3.6.1.4.1.311.10.3.4 Verschlüsselndes Dateisystem
  Application[1] = 1.3.6.1.5.5.7.3.4 Sichere E-Mail
  Application[2] = 1.3.6.1.5.5.7.3.2 Clientauthentifizierung

Exclude leaf cert:
  Chain: da39a3ee5e6b4b0d3255bfef95601890afd80709
Full chain:
  Chain: 193280f838b4e7e9e4c729bb279264171c1c7262
Missing Issuer: CN=msxfaqROOTCA, DC=msxfaq, DC=de
  Issuer: CN=msxfaqROOTCA, DC=msxfaq, DC=de
  NotBefore: 27.07.2008 01:40
  NotAfter: 27.07.2009 01:40
  Subject: E=frank.carius@msxfaq.de, CN="Carius, Frank", OU=Technik, OU=Abteilung, DC=msxfaq, DC=de
  Serial: 188328510000000000bd
  SubjectAltName: Anderer Name:Prinzipalname=fcarius@msxfaq.de, RFC822-Name=frank.carius@msxfaq.de
  Template: User
  Cert: 193280f838b4e7e9e4c729bb279264171c1c7262
Eine Zertifikatkette zu einer vertrauenswürdigen Stammzertifizierungsstelle konnte nicht aufgebaut werden. 0x800b010a (-2146762486 CERT_E_CHAINING)
------------------------------------
Die Zertifikatkette ist unvollständig.
Folgendes Zertifikat wurde nicht gefunden:
    CN=msxfaqROOTCA, DC=msxfaq, DC=de
Das Zertifikat ist ein Endeinheitzertifikat

FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperrfunktion konnte die 
Sperrung nicht überprüfen, da der Sperrserver offline war. 
0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben.
CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

Es bietet sich daher durchaus an, bei einem unklaren Zertifikatsstatus nicht lange mit CAPI2-Debugging zu suchen sondern vielleicht einfach das Zertifikat per HTTPS abzurufen oder bei anderen Protokollen als CER-Datei zu exportieren und zu prüfen.

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 Direct Access 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.

CRL Prüfung abschalten

Ich habe die Möglichkeiten zur Abschaltung der CRL-Prüfung absichtlich ganz an das Ende gestellt.

Zertifikate sind immer das Ziel von Angreifern, um z.B. Angriffe auf die Verbindungen zu fahren. Daher gibt es ja gerade die "Revocation List", mit der eine Zertifizierungsstelle ein Zertifikat ungültig kennzeichnen kann. Für ein einzelnes Zertifikat ist das vielleicht noch tolerierbar aber es gibt auch RooCAs die Zwischenzertifizierungsstellen signiert haben und fast alle PKIs nutzen heute ein zwei oder dreistufiges Modell. Sollte dabei die "Signing-CA" kompromittiert werden, kann die darüberstehende CA diese durch ihre CRL als ungültig erklären. Das geht aber nur, wenn ihr Client die CRLs der Zertifikatskette verifiziert. Ansonsten können sie nur hoffen, dass z.B. ein Windows Update so eine Zertifizierungsstelle explizit in die Liste der gesperrten Zertifikate übernimmt.

Daher ist es wichtig, dass CRLs funktionieren und es ist jedes mal eine Diskussion mit den Firewall und Proxy-Administratoren, dass möglichst alle Clients und Server ohne weitere Authentifizierung zumindest Zugriff auf die CRLs auch im Internet erhalten. Wer das nicht kann, sollte überlegen die CRLs regelmäßig herunter zu laden und eben intern über PinpointDNS-Zonen zu veröffentlichen.

Das generelle Abschalten einer CRL-Prüfung auf einem Client oder Server sollte daher nur die letzte Option sein und auf Systeme beschränkt sein, die nicht mit externen Systemen kommunizieren. Durch das Abschalten verlieren Sie auch die Check gegen eine interne PKI. Der Einsatz von internen Zertifikaten hilft hier also nur dann, wenn Sie die CRL-Prüfungen aktiv lassen.

Es gibt mehrere Stellen, wie sie in die CRL-Checks eingreifen können:

Per Gruppenrichtlinie

Windows stellt als Teil des Betriebssystems entsprechende APIs für die Nutzung und damit auch zur Prüfung von Zertifikaten zur Verfügung. Diese Einstellung wird von den meisten Programmen genutzt, die auf der Crypto-API aufsetzen.

Registrierung

Was die einen per Gruppenrichtlinie machen ist für andere ein PowerShell-Skript, welches z.B. während der Installation mit ausgeführt wird. Ich bevorzuge natürlich die Gruppenrichtlinien, welche eher den Charakter eine "Richtline" haben und quasi immer richtig stehen. Dennoch hier auch als Powershell-. Beachten Sie, dass diese Einstellung auch in allen aktuell angemeldeten Benutzern den Wert einstellt aber nicht bei Benutzern, die gerade nicht aktiv ist.

set-ItemProperty `
   -path "HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\WinTrust\\Trust Providers\\Software Publishing" `
   -name State `
   -value 146944

set-IemProperty `
   -path "REGISTRY::\\HKEY_Users\\.Default\\Software\\Microsoft\\Windows\\CurrentVersion\\WinTrust\\Trust Providers\\Software Publishing" `
   -name State `
   -value 146944

get-ChildItem REGISTRY::HKEY_Users `
   | foreach-object { `
        set-ItemProperty `
           -ErrorAction silentlycontinue  `
           -path ($_.Name + "\\Software\\Microsoft\\Windows\\CurrentVersion\\WinTrust\\Trust Providers\\Software Publishing")  `
           -name State  `
           -value 146944 `
      }

Das hilft also super, wenn Dienstkonten betroffen sind aber nicht bei "natürlichen" Benutzern. Zudem gibt es noch "LocalSystem (S-1-5-18)", "LocalService (S-1-5-19") und "Network Service (S-1-5-20)" u.a., die sie auch konfigurieren können. Die "WellKnownSIDs" dazu sind.

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00

[HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00

[HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
"State"=dword:00023e00

Unschön - Hosts

Es gibt verschiedene Hinweise, dass man den FQDN-Namen der CRL einfach in der lokalen HOSTS auf 127.0.0.1 eintragen sollte. Damit würden dann Programme auch einfach keine Verbindung bekommen aber vom lokalen Host einen "RESET" empfangen und damit nicht lange zu warten.

.NET Config-Dateien

Der vierte Weg ist etwas ruppiger. Das .NET-Framework bzw. Programme, die damit entwickelt und kompiliert wurden, scheren sich nicht wirklich um Einträge in einer Registrierung. DAs -.NET-Framework ist per Definition ja erst mal unabhängig von der Hardware und genau genommen auch vom Betriebssystem und kann daher eine Registrierung nicht immer voraussetzen. Daher stehen die Einstellungen hier in den "CONFG-Dateien. Leider gibt es davon nicht nur eine. Folgender Code aus dem Sharepoint Autoinstaller Skript macht für Sharepoint genau diese Änderungen.

# Auszug aus dem AutoSPInstaller (http://autospinstaller.codeplex.com) um SharePoint quasi automatisch zu installieren


Function DisableCRLCheck()
{
   Write-Host `
      -ForegroundColor White " - Disabling Certificate Revocation List (CRL) check..."
   ForEach($bitsize in ("","64"))  {			
      $xml = [xml](Get-Content $env:windir\Microsoft.NET\Framework$bitsize\v2.0.50727\CONFIG\Machine.config)
      If (!$xml.DocumentElement.SelectSingleNode("runtime")) { 
         $runtime = $xml.CreateElement("runtime")
         $xml.DocumentElement.AppendChild($runtime) | Out-Null
      }
      If (!$xml.DocumentElement.SelectSingleNode("runtime/generatePublisherEvidence")) {
         $gpe = $xml.CreateElement("generatePublisherEvidence")
         $xml.DocumentElement.SelectSingleNode("runtime").AppendChild($gpe)  | Out-Null
      }
      $xml.DocumentElement.SelectSingleNode("runtime/generatePublisherEvidence").SetAttribute("enabled","false")  | Out-Null
      $xml.Save("$env:windir\Microsoft.NET\Framework$bitsize\v2.0.50727\CONFIG\Machine.config")
   }
}

Weitere Links