Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 12 Active Directory-Zertifikatdienste
Pfeil 12.1 Einige Anwendungsszenarien
Pfeil 12.1.1 Internet-Authentifizierung und Verschlüsselung
Pfeil 12.1.2 Sichere E-Mail
Pfeil 12.1.3 Codesignatur
Pfeil 12.1.4 IP-Verschlüsselung
Pfeil 12.1.5 Anmeldung mit Smartcard
Pfeil 12.1.6 Wireless Authentification (802.1X)
Pfeil 12.1.7 Fazit
Pfeil 12.2 Zertifikatsdienste installieren/Migration (einstufige Architektur)
Pfeil 12.3 Zertifikate aus Sicht des Clients
Pfeil 12.4 Zertifizierungspfad
Pfeil 12.5 Zertifikatvorlagen
Pfeil 12.6 Weboberfläche
Pfeil 12.7 Mehrstufige Architekturen
Pfeil 12.7.1 Rollen
Pfeil 12.7.2 Architekturen
Pfeil 12.8 Autoenrollment und automatische Zertifikatanforderung
Pfeil 12.8.1 Automatische Zertifikatanforderung
Pfeil 12.8.2 Autoenrollment
Pfeil 12.9 Zertifikate für Websites
Pfeil 12.10 Zertifikatssperrlisten
Pfeil 12.10.1 Funktionsweise – ganz grob
Pfeil 12.10.2 Sperrlisteneinträge
Pfeil 12.10.3 Gültigkeit einer Sperrliste
Pfeil 12.10.4 Zertifikatgültigkeit überprüfen
Pfeil 12.10.5 Der Cache
Pfeil 12.10.6 ISA Server zum Veröffentlichen der Speicherortes verwenden
Pfeil 12.11 Das Online Certificate Status Protocol (OCSP)
Pfeil 12.11.1 Konfiguration des Online-Responders
Pfeil 12.11.2 Anpassung der Zertifizierungsstelle
Pfeil 12.11.3 Testen
Pfeil 12.11.4 ISA Server-Veröffentlichung
Pfeil 12.12 Zweistufige Architektur implementieren
Pfeil 12.12.1 Offline-CA installieren und konfigurieren
Pfeil 12.12.2 Zertifikat und Sperrliste dem Unternehmenszertifikatserver und dem Active Directory hinzufügen
Pfeil 12.12.3 Unternehmens-CA installieren
Pfeil 12.12.4 Sperrlisten-Verteilungspunkt mit ISA Server veröffentlichen
Pfeil 12.13 Zertifikate und Windows Mobile
Pfeil 12.13.1 Pocket PC und Pocket PC Phone Edition
Pfeil 12.13.2 Smartphone
Pfeil 12.14 Zertifikate und das iPhone


Galileo Computing - Zum Seitenanfang

12.10 Zertifikatssperrlisten Zur nächsten ÜberschriftZur vorigen Überschrift

Ich habe in diesem Buch bisher immer darauf verwiesen, dass ein Zertifikat drei Kriterien erfüllen muss, um als gültig angesehen zu werden:

  • Das Zertifikat muss auf den aufgerufenen Namen ausgestellt sein.
  • Es muss zeitlich gültig sein.
  • Es muss vertrauenswürdig sein.

Im Grunde genommen ignorieren wir damit eine wichtige weitere Forderung, nämlich dass das Zertifikat nicht auf der Sperrliste stehen darf. Sinn von Sperrlisten ist, dass eine Zertifizierungsstelle die Möglichkeit hat, Zertifikate zurückzurufen, beispielsweise falls das Zertifikat korrumpiert worden ist oder der Mitarbeiter, für den das Zertifikat erzeugt wurde, nicht mehr im Unternehmen tätig ist.

Die Zertifikatssperrlisten gibt es schon so lange wie es Zertifikate gibt, trotzdem haben sich die meisten Unternehmen mit eigener PKI nie wirklich Gedanken über das Thema Sperrlisten gemacht.

Die Sperrlisten rücken aber für die Unternehmen aus zwei Gründen stärker in den Fokus:

  • Je intensiver mit Zertifikaten gearbeitet wird, desto wichtiger ist es, Zertifikate sperren zu können. Das klingt zwar trivial, aber es sind ja meistens eher die offensichtlichen Dinge, die mitunter Probleme bereiten … Denken Sie an den Mitarbeiter, der das Unternehmen verlässt – vielleicht sogar im Streit. Das Zertifikat, das er unter Umständen von seinem Notebook kopiert hat, könnte (!) vielleicht für irgendeinen Zweck missbräuchlich verwendet werden.
  • Einige neue Funktionen, zu nennen wären beispielsweise SSTP (Secure Socket Tunneling Protocol, sozusagen ein VPN auf HTTPS-Basis) oder DirectAccess (Feature von Windows 7) setzen zwingend (!) eine erfolgreiche Überprüfung der Zertifikatssperrliste voraus.

In Unternehmen und Organisationen war die Zertifikatssperrliste bislang nicht so ein großes Thema, weil ein Browser oder auch Funktionen wie Outlook Anywhere eben nicht den Dienst verweigern, wenn der Sperrstatus eines Zertifikats nicht überprüft wurde. Es gilt dann das In-dubio-pro-reo-Prinzip, im Zweifelsfall wird also für den Angeklagten entschieden – das Zertifikat wird schon nicht gesperrt sein.

Dass beispielsweise SSTP und DirectAccess eine korrekt implementierte Sperrliste fordern, ist eigentlich sehr lobenswert, wird aber die meisten Unternehmen und Organisationen zwingen, erstmalig ernsthaft über dieses Thema nachzudenken, denn die Sperrliste muss auch extern verfügbar sein!

Meiner Erfahrung nach haben die meisten Unternehmen, die für den einen oder anderen Dienst Zertifikate benötigten, eine einstufige Unternehmenszertifizierungsstelle eingerichtet – in etwa so wie zu Beginn des Kapitels gezeigt. Das ist keine große Sache und geht mehr oder weniger nach dem »Weiter=>Weiter=>Fertig-Prinzip«. Dagegen ist ja auch zunächst nichts einzuwenden. In den Zertifikaten sind dann auch zwei Sperrlisten-Verteilungspunkte eingetragen (Abbildung 12.55):

  • Die Sperrliste wird von der Zertifizierungsstelle regelmäßig im Active Directory veröffentlicht, die ldap://-URL verweist darauf.
  • Weiterhin gibt es eine über HTTP erreichbare Sperrliste, zumindest dann, wenn die Komponenten für die Webregistrierung bei der Einrichtung der Zertifizierungsstelle mitinstalliert worden sind.

Abbildung 12.55 Die Sperrlisten-Verteilungspunkte sind standardmäßig nur intern zu erreichen.

Festzuhalten ist, dass beide Sperrlisten-Verteilungspunkte nur für interne Clients erreichbar sind. Um das Beispiel mit SSTP und DirectAccess weiter zu strapazieren: Beide Zugriffstechnologien fragen die Zertifikatssperrliste ab, bevor die Verbindung zum internen Netz realisiert werden konnte – leider verloren.

Nun ist es kein Hexenwerk, die Zertifikatssperrliste auf einen öffentlich zugänglichen Webserver zu kopieren und die Sperrlisten-Verteilungspunkte der ausgestellten Zertifikate ein wenig anzupassen. Ich denke, dass es aber nicht schaden kann, das Thema Sperrung von Zertifikaten ein wenig intensiver zu betrachten, denn es gibt ein paar kleinere und größere Fallen, in die man durchaus treten kann.


Galileo Computing - Zum Seitenanfang

12.10.1 Funktionsweise – ganz grob Zur nächsten ÜberschriftZur vorigen Überschrift

Auf Abbildung 12.56 sehen Sie den Zertifizierungspfad eines Zertifikats, das von einer zweistufigen PKI herausgegeben wurde:

  • Die Stammzertifizierungsstelle UBINFROOTZERT hat das Zertifikat für die untergeordnete Zertifizierungsstelle ubinfCA erstellt.
  • Die Zertifizierungsstelle ubinfCA hat ein Zertifikat für den Webserver ubinfWeb01.boddenberg.de erstellt.

Abbildung 12.56 Ein von einer zweistufigen PKI herausgegebenes Zertifikat

Wenn ein Programm oder Dienst nun prüfen möchte, ob das Zertifikat, mit dem sich der Server ubinfWeb01.boddenberg.de authentifiziert, direkt oder indirekt gesperrt ist, muss dieser prinzipiell drei Prüfungen durchführen:

  • Das Zertifikat ubinfWeb01.boddenberg.de könnte gesperrt sein.
  • Das Zertifikat der Zertifizierungsstelle ubinfCA könnte gesperrt worden sein. Dadurch werden implizit alle von dieser Zertifizierungsstelle ausgegebenen Zertifikate ungültig.
  • Im schlimmsten Fall könnte auch das Stammzertifikat UBINFROOTCERT gesperrt worden sein – beispielsweise weil der private Schlüssel dieses Zertifikats korrumpiert worden ist.

Ich habe den Prozess auf Abbildung 12.57 einmal visualisiert:

  • Der Computer prüft zunächst, ob das Zertifikat überhaupt vertrauenswürdig ist.
  • Dann liest er aus dem zu prüfenden Zertifikat (in diesem Fall ausgestellt für den Server ubinfWeb01) den Eintrag für die Zertifikatssperrliste.
  • Er greift auf die Sperrliste zu und schaut nach, ob das Zertifikat dort als gesperrt aufgeführt ist.
  • Dann beschafft er sich das Zertifikat der Zertifizierungsstelle, die das Zertifikat ausgegeben hat, in diesem Fall ubinfCA.
  • Im Zertifikat von ubinfCA gibt es ebenfalls einen Eintrag für eine Sperrliste.
  • Die Sperrliste von ubinfCA wird geladen, und es wird geprüft, ob das ubinfCA-Zertifikat auf der Sperrliste aufgeführt ist.
  • Dann geht es zum nächsten Zertifikat der Kette, dies ist dann aber in diesem Fall schon das Stammzertifikat.

Abbildung 12.57 In einer mehrstufigen PKI werden auch die Sperrlisten der Zwischenzertifikate überprüft.

Vermutlich fragen Sie sich beim Betrachten von Abbildung 12.57, warum das Stammzertifikat keinen Verweis auf eine Sperrliste hat. Technisch wäre das problemlos möglich, es ist allerdings gängige Praxis, das Stammzertifikat nicht mit einem Sperrlisteneintrag zu versehen.

Sie können das übrigens selbst verifizieren, wenn Sie die standardmäßig installierten Stammzertifikate im lokalen Zertifikatsspeicher betrachten. Auf Abbildung 12.58 sehen Sie ein VeriSign-Stammzertifikat: ohne Sperrlisteneinträge.

Wenn Sie ein Stammzertifikat mit einer Windows Server 2008-Stammzertifizierungsstelle erzeugen (gilt auch für Windows Server 2008 R2), hat das Stammzertifikat keine Sperrlisteneinträge. Windows Server 2003 hat sich übrigens noch anders verhalten; dort hatten Stammzertifikate diesen Eintrag, es sei denn, es waren anderslautende Einträge in einer CAPolicy.inf-Datei vorhanden.

Abbildung 12.58 Es ist mittlerweile gängige Praxis, in Stammzertifikaten keine Sperrlisteneinträge zu integrieren.

Werfen wir einen Blick auf die Sperrlisteneinträge von real existierenden Zertifikaten (Abbildung 12.59):

  • Links sehen Sie ein von einer öffentlichen Zertifizierungsstelle herausgegebenes Zertifikat. Als Verteilungspunkt ist dort »nur« eine öffentlich erreichbare HTTP-URL hinterlegt.
  • Rechts ist das Zertifikat einer internen Zertifizierungsstelle abgebildet. Dort sind als Sperrlisten-Verteilungspunkt sowohl ein Ort im Active Directory (ldap://…) als auch eine öffentlich erreichbare URL (http://...) eingetragen. Damit eine solche Konfiguration zustande kommt, ist übrigens ein wenig manuelle Nacharbeit an der eigenen Zertifizierungsstelle erforderlich, sie ist aber gleichwohl sinnvoll: Im internen Netz befindliche Clients können die Sperrliste einfach aus dem Active Directory laden. Sind die Clients unterwegs, haben Sie über den öffentlichen Verteilungspunkt ebenfalls Zugriff – das ist beispielsweise für die Nutzung von Technologien wie DirectAccess oder SSTP erforderlich.

Abbildung 12.59 Die Sperrlisteneinträge in den Zertifikaten einer kommerziellen (links) und einer »internen« Zertifizierungsstelle


Galileo Computing - Zum Seitenanfang

12.10.2 Sperrlisteneinträge Zur nächsten ÜberschriftZur vorigen Überschrift

Die Konfiguration der Sperrlisteneinträge können Sie entweder mit Certutil oder dem grafischen Zertifizierungsstellen-Konfigurationswerkzeug vornehmen. Auf der Registerkarte Erweiterungen des Eigenschaftendialogs können Sie beliebig viele Orte für die Zertifikatssperrliste eintragen – einige werden bereits vorhanden sein. Grob gesagt gibt es zwei Typen:

  • Orte, an denen die Zertifikatdienste Sperrlisten erstellen. Dies können Orte im Dateisystem oder im Active Directory sein.
  • Orte, die in den Zertifikaten für den Abruf der Sperrliste eingetragen werden. Sinnvoll sind hier solche im Active Directory oder auf Webservern.

Ein Ort kann sowohl ein Erstellungsort als auch ein »Abrufort« sein, bei dem bei einer Unternehmenszertifizierungsstelle standardmäßig vorhandenen Active Directory-Ort ist das normalerweise der Fall. Wie ein Ort behandelt wird, wird durch die Checkboxen gesteuert:

  • Auf Abbildung 12.60 sehen Sie den standardmäßig vorhandenen Eintrag für einen Speicherort im Dateisystem. Die Zertifizierungsstelle veröffentlicht hier regelmäßig die Sperrlisten, da die Checkboxen Sperrlisten an diesem Ort veröffentlichen und Deltasperrlisten an diesem Ort veröffentlichen aktiviert sind. Diese Location (also der Pfad c:\windows\...) wird übrigens nicht in die Zertifikate eingetragen – das wäre auch so dermaßen sinnlos dass diese Option gar nicht erst anwählbar ist. Anzumerken wäre, dass dieser Pfad (c:\windows\system32\CertSrv\CertEnroll) mit einer Freigabe versehen ist und, falls die Webregistrierungsdienste installiert worden sind, als virtuelles Verzeichnis einer IIS-Website veröffentlicht ist.

Abbildung 12.60 In diesem Verzeichnis werden die Sperrlisten standardmäßig veröffentlicht.

  • Abbildung 12.61 zeigt einen von mir nachträglich hinzugefügten Speicherort, nämlich eine öffentliche erreichbare URL. Diese URL soll in den Zertifikaten veröffentlicht werden. Dafür, dass diese URL tatsächlich eine Zertifikatssperrliste enthält, sind Sie selbst verantwortlich; die Zertifikatdienste können hier nicht automatisch Sperrlisten veröffentlichen. Dementsprechend sind einige Optionen nicht anwählbar.

Mehrere Sperrlistenorte

Es können übrigens beliebig viele Sperrlistenorte eingetragen werden. Allerdings sollten Sie das sorgfältig planen: Wenn der Zertifikatdienst-Client erst zahlreiche Sperrlistenorten ausprobieren muss, die er nicht erreichen kann, kostet das natürlich Zeit. Insofern sollte die Wahl der Sperrlistenorte gut überlegt sein.


Abbildung 12.61 Hier ist eine externe URL als Speicherort für die Zertifikatssperrlisten angegeben. Sie wird in die Zertifikate einbezogen.

Abbildung 12.62 Hier wird definiert, unter welcher URL das Zertifikat der Zertifizierungsstelle erreichbar ist.

Neben der Sperrliste muss in den Zertifikaten der Zugriff auf Stelleninformationen veröffentlicht werden (Abbildung 12.62). Wenn Sie nochmals zu Abbildung 12.57 zurückblättern, wird klar, worum es geht: Eventuell kennt der überprüfende Zertifikats-Client zwar das Stammzertifikat, nicht aber die Zwischenzertifikate. Die Stelleninformationen verweisen auf einen Ort, von dem das jeweils ausstellende Zertifikat heruntergeladen werden kann. Die Konfiguration funktioniert analog zu den Sperrlisten. Auch hier ist es sinnvoll, einen Active Directory-Speicherort und einen öffentlich erreichbaren Webspeicherort zu konfigurieren. ist.


Galileo Computing - Zum Seitenanfang

12.10.3 Gültigkeit einer Sperrliste Zur nächsten ÜberschriftZur vorigen Überschrift

Die Gültigkeitsdauer einer Sperrliste kann in der Zertifizierungsstelle festgelegt werden. Es gibt dabei allerdings ein kleines Problem, denn das geht nicht mit der grafischen Oberfläche. Sie müssen Certutil bemühen.

Hier ein kleines Konfigurationsbeispiel: Um die Gültigkeit der Sperrliste auf eine Woche zu setzen und alle zwei Tage eine Deltasperrliste zu erzeugen, geben Sie folgende Befehle ein:

Certutil –setreg CA\CRLPeriod weeks
Certutil –setreg CA\CRLPeriodUnits 1
Certutil –setreg CA\CRLDeltaPeriod days
Certutil –setreg CA\CRLDeltaPeriodUnits 2

Nach Eingabe dieser Befehle müssen Sie die Zertifizierungsstelle neu starten (net stop certsvc, net start certsvc).


Galileo Computing - Zum Seitenanfang

12.10.4 Zertifikatgültigkeit überprüfen Zur nächsten ÜberschriftZur vorigen Überschrift

Wer bereits mit Zertifikatssperrlisten von selbst ausgestellten Zertifikaten zu tun hatte, hat vermutlich die Erfahrung gemacht, dass nicht immer alles so funktioniert, wie man es sich im stillen Kämmerlein vorgestellt hat. Das ist leider meistens so (nicht nur in der IT, auch im richtigen Leben), und es schlägt die Stunde der Werkzeuge zur Fehlersuche.

Bei der Arbeit mit Zertifikatssperrlisten gibt es regelmäßig zwei Probleme:

  • Die URL ist nicht erreichbar.
  • Der Speicherort ist zwar grundsätzlich erreichbar, allerdings ist dort trotzdem keine Sperrliste abrufbar.

Es gibt Möglichkeiten, die Gültigkeit eines Zertifikats nebst Sperrlisten zu überprüfen.

Protokollierung aktivieren

Die erste Möglichkeit ist die Protokollierung der CAPI2 (CAPI = Crypto API) zu aktivieren. Das ist bei Systemen ab Windows Vista (Windows Server 2008, Windows Server 2008 R2, Windows 7) möglich. Navigieren Sie in der Ereignisanzeige zu dem auf Abbildung 12.63 gezeigten Knoten, und wählen Sie in dessen Kontextmenü den Menüpunkt Protokoll aktivieren. Die Protokollierung ist sofort eingeschaltet.

Abbildung 12.63 In der Ereignisanzeige kann die Protokollierung für CAPI2 aktiviert werden.

Beim Aufbau und der Überprüfung der Zertifikatkette werden diverse Einträge generiert, sowohl erfolgreiche als auch fehlgeschlagene Versuche. Einen Auszug des Protokolls sehen Sie auf Abbildung 12.64, der jeweilige Schritt (zum Beispiel Objekt aus Netzwerk abrufen oder Sperrung überprüfen) ist angenehmerweise im Klartext zu lesen.

Die Details zu dem fehlerhaften Eintrag (Abbildung 12.64, fünfter von unten) sehen Sie auf Abbildung 12.65. Der Client befand sich im Internet und konnte folglich auf das Active Directory nicht zugreifen. Demzufolge schlug der Zugriff auf die Sperrliste fehl.

Wenn man das Protokoll weiter verfolgt, ist zu erkennen, dass der nächste Versuch, nämlich der Zugriff über den HTTP-Sperrlisten-Veröffentlichungsort, erfolgreich ist und die Sperrung somit überprüft werden kann. Eine Fehlermeldung muss also nicht notwendigerweise bedeuten, dass etwas schiefläuft; Sie haben mit dem Protokoll die Möglichkeit, den vollständigen Verlauf der Zertifikatüberprüfung zu verfolgen, was Sie eben auch tun müssen.

Abbildung 12.64 In dem Protokoll werden die Ereignisse der Crypto API erfasst.

Abbildung 12.65 Ein Eintrag des Ereignisprotokolls: Auf die LDAP-URL kann über das Internet nicht zugegriffen werden.

Zertifikat überprüfen

Die Protokollierung ist zwar durchaus hilfreich, vermutlich haben Sie aber auch den Wunsch, ein Zertifikat gezielt zu überprüfen. So ganz komfortabel ist es ja dann doch nicht, wenn Sie erst ein Szenario bauen müssen, bei dem eine Anwendung das Zertifikat überprüft, damit Sie die benötigten Einträge im Protokoll erhalten.

Mittels Certutil kann ein beliebiges Zertifikat überprüft werden; am einfachsten ist es, wenn es im Dateisystem vorhanden ist. Der Befehl lautet dann:

certutil –verify zertifikatdatei.cer.

Auf Abbildung 12.66 habe ich Folgendes getan:

  • Ich habe im Browser die Galileo-Website aufgerufen und das übermittelte Zertifikat in eine Datei gespeichert.

Abbildung 12.66 Die Überprüfung eines von einer öffentlichen Zertifizierungsstelle ausgestellten Zertifikats.

  • Mittels Certutil habe ich die Gültigkeit des Zertifikats nebst Sperrungen überprüft.
  • Das Ergebnis: gültig.

Die Prüfung ist eventuell nicht ganz aussagekräftig. Eine Zertifikatssperrliste, die einmal heruntergeladen worden ist, wird während ihrer Gültigkeitsdauer im Cache des lokalen PCs gespeichert und verwendet. Das könnte dazu führen, dass die Zertifikatssperrliste erfolgreich geladen wurde, als sich der PC im LAN befand. Ist der Client im Internet, wird er die Sperrliste aus dem Cache abrufen, und es wird nicht überprüft, ob die Sperrliste überhaupt erreichbar ist. Dass jede URL überprüft wird, können Sie erreichen, indem Sie den Parameter -urlfetch verwenden, also folgende Befehlszeile eingeben:

Certutil –verify –urlfetch zertifikatname.cer

Auf Abbildung 12.67 sehen Sie einen Auszug aus der Zertifikatüberüfung mit dem Parameter -urlfetch, der Client befand sich im Internet:

  • Der Zugriff auf das Active Directory (ldap://…) schlägt fehl.
  • Der anschließende Zugriffsversuch auf die HTTP-URL gelingt.
  • Beim Zugriff auf die Deltasperrliste verhält es sich ebenso.

Abbildung 12.67 Zugriff aus dem Internet: Der LDAP-Speicherort kann nicht angesprochen werden, der HTTP-Speicherort klappt.

Abbildung 12.68 zeigt den Zugriff auf die Sperrliste der Stammzertifizierungsstelle. Diese ist hier nicht im Active Directory gespeichert, sondern es gibt »nur« einen HTTP-Speicherort. Da alles korrekt konfiguriert ist, gibt es nur erfolgreiche Zugriffe und keinerlei Fehlversuche. Gäbe es bei der Überprüfung der Zertifikatkette HTTP-Speicherorte, auf die kein Zugriff möglich ist, würde das mit dieser Überprüfung einfach zu erkennen sein.

Abbildung 12.68 Das Stammzertifikat wird geprüft. Ein LDAP-Speicherort ist hier nicht vorhanden.

Abbildung 12.69 zeigt die letzten Zeilen der Ausgabe von Certutil mit dem Ergebnis: erfolgreich abgeschlossen. Es konnte zwar nicht auf jede URL zugegriffen werden (das Active Directory war nicht erreichbar), trotzdem konnte der Sperrstatus des Zertifikats erfolgreich überprüft werden.

Abbildung 12.69 Die Überprüfung war erfolgreich.

In der Praxis gibt es hin und wieder den Fall, dass eine Anwendung lapidar meldet, dass die Gültigkeit eines Zertifikats nicht überprüft werden konnte, nennt aber nicht das genaue Problem.

Mit Certutil –verify –urlfetch lässt sich sehr präzise ermitteln, an welcher Stelle der Zertifikatkette das Problem liegt. Das hat mir schon gute Dienste geleistet, denn sonst bleibt wirklich nur das Raten.

Anzumerken wäre noch, dass die Schritte, die von Certutil durchgeführt werden, in dem zuvor erwähnten Protokoll verzeichnet werden.


Galileo Computing - Zum Seitenanfang

12.10.5 Der Cache Zur nächsten ÜberschriftZur vorigen Überschrift

Wie ich bereits erwähnt habe, werden Sperrlisten und Zertifikate im Cache des lokalen Zertifikatdienst-Clients gespeichert. Diesen Cache kann man auslesen und zwar mit dem Befehl certutil –urlcache CRL, der alle zwischengespeicherten Zertifikatssperrlisten zeigt. Bei der im vorherigen Abschnitt durchgeführten Überprüfung des Zertifikats wurden drei Sperrlisten geladen und zwischengespeichert (Abbildung 12.70; vor Überprüfung des Zertifikats habe ich den Cache mittels certutil –urlcache CRL delete gelöscht):

  • UBINFROOTCERT.crl ist die Sperrliste der Stammzertifizierungsstelle.
  • ubinfCA.crl ist die Sperrliste der Unternehmenszertifizierungsstelle.
  • ubinfCA+crl ist die Deltasperrliste der Unternehmenszertifizierungsstelle.

Abbildung 12.70 Nach der Überprüfung des Zertifikats sind die Sperrlisten im Cache.

Man kann auf diese Weise übrigens auch erkennen, dass der Browser (Internet Explorer 8) beim Zugriff auf eine SSL-geschützte Website die Sperrliste des Zertifikats überprüft. Dazu habe ich Folgendes gemacht:

  • Cache löschen: certutil –urlcache CRL delete
  • … und schon sind einige VeriSign-Sperrlisten im Cache (Abbildung 12.71). Wenn Sie das von Amazon verwendete Zertifikat überprüfen, werden Sie feststellen, dass in der Tat ein VeriSign-Zertifikat verwendet wird.

Zertifikatkette wird überprüft

Der Internet Explorer beschwert sich zwar nicht, wenn eine Zertifikatssperrliste nicht im Zugriff ist. Wie man anhand des Protokolls und des Caches sehen kann, wird die Zertifikatkette nebst Sperrlisten aber trotzdem überprüft – sofern möglich.


Abbildung 12.71 Der Beweis: Beim Zugriff auf eine SSL-geschützte Website tauchen die Sperrlisten im Cache auf.


Galileo Computing - Zum Seitenanfang

12.10.6 ISA Server zum Veröffentlichen der Speicherortes verwenden topZur vorigen Überschrift

Wenn Sie bei der Installation einer Zertifizierungsstelle auch den Rollendienst Zertifizierungsstellen-Webregistrierung installiert haben, steht bereits ein Webspeicherort für die Zertifikatssperrlisten und Stelleninformationen zur Verfügung, der aber zunächst nur aus dem internen Netz zu erreichen ist (http://servername/CertEnroll). Da dieses virtuelle Verzeichnis auf den Pfad C:\windows\system32\CertSrv\CertEnroll verweist, sind dort automatisch die aktualisierten Sperrlisten vorhanden.

Sie können natürlich den Inhalt von C:\windows\system32\CertSrv\CertEnroll regelmäßig auf einen beliebigen anderen Webserver kopieren; alternativ können Sie genau dieses virtuelle Verzeichnis mit dem ISA Server über eine Website-Veröffentlichungsregel veröffentlichen. Da ISA Server bei recht vielen Unternehmen und Organisationen verwendet werden, um beispielsweise Exchange (Outlook Web Access, Exchange ActiveSync) oder SharePoint sicher im Web zu veröffentlichen, liegt der Gedanke durchaus nah, diesen Weg auch für die Zertifikatssperrlisten zu gehen. Ich zeige Ihnen nun sozusagen im Schnelldurchlauf, wie das mit ISA Server 2006 zu bewerkstelligen ist.

Die Veröffentlichung einer Website beginnt mit dem Aufruf des Assistenten zur Erstellung einer Website-Veröffentlichungsregel (Abbildung 12.72).

Einer der ersten Schritte des Assistenten dient zur Festlegung, ob eine SSL-Verbindung verwendet werden soll. Normalerweise ist das die empfehlenswerte Option, in diesem Fall aber nicht. Wenn bei der Zertifikatsprüfung auf eine Sperrliste zugegriffen werden soll, die an einem mit einem Zertifikat geschützten Speicherort liegt, müsste auch dessen Gültigkeit überprüft werden. Eventuell bauen Sie dann eine Endlosschleife. Entscheiden Sie sich also für eine ungesicherte HTTP-Verbindung. Da die Zertifikatssperrlisten ohnehin nicht geheim und für jeden herunterladbar sind, stellt die ungesicherte Verbindung in diesem Fall kein Problem dar (Abbildung 12.73).

In einem der nächsten Schritte wird der zu veröffentlichende Pfad festgelegt. Wenn Sie auf den automatisch erstellten Verteilungspunkt zugreifen möchten, lautet der hier einzutragende Pfad /CertEnroll/* (Abbildung 12.74, links).

Abbildung 12.72 Mit diesem Assistenten beginnt die Veröffentlichung einer Website.

Abbildung 12.73 Achten Sie darauf, eine unsichere Verbindung zu wählen.

Im nächsten Schritt muss festgelegt werden, auf welchen öffentlichen Namen (= Hostheader) der ISA Server reagieren soll. Tragen Sie hier den Hostnamen ein, der in den Zertifikaten als öffentlicher Sperrlisten-Verteilungspunkt hinterlegt ist, in diesem Fall certs.boddenberg-technik.de. Vergessen Sie nicht, dass Sie einen entsprechenden DNS-Eintrag für das öffentliche Internet setzen müssen (Abbildung 12.74, rechts).

ISA Server »hört« Anforderungen auf einem Port mit einem Weblistener ab. In diesem Fall wird ein Weblistener benötigt, der den HTTP-Port (80) abhört. Wichtig dabei ist, dass der Weblistener keine Authentifizierung erzwingt (Abbildung 12.75).

Abbildung 12.74 Legen Sie fest, welches Verzeichnis veröffentlicht werden soll und mit welchem öffentlichen Namen gearbeitet wird.

Abbildung 12.75 Der Weblistener darf keine Authentifizierung erzwingen.

In den Themenbereich Authentifizierung passen im weiteren Sinne auch die letzten beiden Dialoge des Assistenten (Abbildung 12.76):

  • Eine Authentifizierung an dem nachgelagerten Webserver ist nicht erforderlich, somit ist eine Delegierung (bedeutet in etwa Weiterleitung) der Anmeldung des Benutzers auch nicht notwendig. Wir haben ja ohnehin im vorherigen Schritt festgelegt, dass eine Authentifizierung durch den Weblistener nicht vorgenommen wird.
  • Zum Zugriff zugelassen werden Alle Benutzer; in dieser Gruppe sind auch anonyme, also nicht authentifizierte Benutzer enthalten.

Abbildung 12.76 Eine Delegierung der Authentifizierung darf nicht eingestellt werden. Zum Zugriff zugelassen werden alle Benutzer.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de