Windows Server Longhorn: OCSP bei den Zertifikatsdiensten, Teil 2

Wie im ersten Teil der Serie ausgeführt wurde, müssen für das OCSP zunächst die Zertifikatsdienste und zusätzlich die IIS eingerichtet sein. Außerdem werden die Windows Activation Services benötigt. Anschließend kann das Snap-In für OCSP, das als Online Responder Management bezeichnet wird, genutzt werden. Die Aufgabe des Tools ist es, die OCSP-Dienste zu steuern. Es geht also nicht darum, Zertifikate zu sperren, das wird in gewohnter Weise bei den Zertifikatsdiensten gemacht.

Vielmehr geht es darum, den Betrieb der Server zu steuern, an die OCSP-Anforderungen gestellt werden. OCSP selbst ist also aus Sicht dessen, der sich um das eigentliche Zertifikatsmanagement kümmert, weitgehend transparent. Die Herausforderung, für die es das Online Responder Management gibt, ist der gesicherte Betrieb. Das ist schon deshalb wichtig, weil je nach Konfiguration von Anwendungen, die Zertifikate akzeptieren, unter Umständen keine Überprüfung von Zertifikaten erfolgen kann, wenn die OCSP-Infrastruktur nicht verfügbar ist.

Serie

Teil 1	Grundlagen zu OSCP und Einrichtung der Zertifikatsdienste mit OCSP
Teil 2	Die Konfiguration und Nutzung von OCSP

Responder-Eigenschaften

Der erste Konfigurationsschritt ist die Festlegung der Eigenschaften des Responders, der aktuell verwaltet wird. Mit dem Befehl Online Responder Properties im Kontextmenü des Knotens Online Responder kann dieses Dialogfeld geöffnet werden.

Im Register Web Proxy finden sich Parameter für die Steuerung des Verhaltens der IIS-Anwendung, die vom OCSP verwendet wird. Die Standardwerte sind 50 Threads und 5.000 Cache-Einträge. Diese Werte sind relativ hoch gewählt, sodass sie auch für größere Installationen in der Regel ausreichen. In kleineren Netzwerken kann man die Werte deutlich reduzieren und mit 5 bis 10 Threads und dem Minimalwert von 1.000 Cache-Einträgen arbeiten.

Im Register Audit wird angegeben, welche Ereignisse des OCSP-Dienstes überwacht werden. So können beispielsweise für das Starten und Beenden oder für Änderungen an den Konfigurations- und Sicherheitseinstellungen des Dienstes Einträge in das Sicherheitsprotokoll des jeweiligen lokalen Windows-Systems geschrieben werden. Da der Dienst eine sehr wichtige Rolle in derSicherheitsinfrastruktur von Windows-Umgebungen spielt, wenn mit Zertifikaten gearbeitet wird, sollten die Ereignisse auch konsequent überwacht werden.

Im Register Sicherheit wird festgelegt, wer administrative Berechtigungen für den Dienst hat. Ein Netzwerkdienst darf Anforderungen weiterleiten, die Berechtigung zur Verwaltung des Dienstes haben dagegen zunächst nur die Administratoren. Hier können aber bei Bedarf weitere Benutzer hinzugefügt werden.

Revocation-Konfiguration

Der nächste Schritt ist die Konfiguration der Revocation, also der Information über abgelehnte Zertifikate. Im Knoten Recovation Configuration lässt sich die Aktion Add Revocation Configuration auswählen. Dabei wird ein Assistent gestartet, mit dem die Konfiguration festgelegt werden kann. Es können auch mehrere Konfigurationen erstellt werden, um mit einer OCSP-Infrastruktur beispielsweise mehrere CAs zu unterstützen. Der erste Schritt ist die Festlegung eines Namens für die Konfiguration. Hier sollte wie immer in solchen Fällen ein eindeutiger, sprechender Name gewählt werden.

Anschließend muss das Zertifikat der Zertifizierungsstelle ausgewählt werden, für die diese Konfiguration gilt (Bild 2). Eine Konfiguration gilt also immer für genau eine Zertifizierungsstelle. Für jede Zertifizierungsstelle, deren ausgestellte Zertifikate durch OCSP geprüft werden sollen, muss eine Konfiguration erstellt werden. Das Zertifikat kann für eine Enterprise CA direkt von dieser angefordert werden. Das bietet sich beim Betrieb von eigenen CAs an. In diesem Fall findet sich das Zertifikat in der Regel im Active Directory oder sogar auf dem lokalen System. Eine Alternative dazu ist die Verwendung eines Zertifikats aus dem lokalen Zertifikatsspeicher. Damit können Zertifikate auch für CAs, die nicht im Active Directory verwaltet werden, importiert werden. Außerdem kann auch auf Dateien zugegriffen werden.

Im folgenden Schritt muss die CA ausgewählt werden. Welche Optionen hier angezeigt werden, hängt von der im vorangegangenen Schritt gewählten Konfiguration ab. Nachfolgend wird das für die Speicherung eines CA-Zertifikats – also eines Zertifikats einer vertrauenswürdigen Stammzertifizierungsstelle – im Active Directory beschrieben. In diesem Fall gibt es die Option Browse CA certificates published in Active Directory. Das ist auch die Standardoption. Wenn sie gewählt wurde, kann man mit Browse nach dem Zertifikat im Active Directory suchen und es auswählen. Durch Anklicken von View Selected CA certificate im unteren Bereich kann man sich noch die Details zu dem Zertifikat anzeigen lassen. Als Alternative kann man auch die Option Browse for CA Computer verwenden und über den Computernamen nach der CA suchen. Nachdem dieser Festlegung muss definiert werden, wie die Revocation-Information, die von OCSP gesendet wird, signiert wird.

Geeignetes Zertifikat

Das Zertifikat, das für die Signatur verwendet wird, muss auch vom Client verwendet werden. Hier gibt es mehrere Optionen (Bild 3), wobei man aber in Active Directory-integrierten Umgebungen mit der Option Automatically select signing certificate arbeiten kann. Wichtig ist aber, dass ein für die Signatur von Nachrichten geeignetes Zertifikat vorhanden ist. Optional kann man mit Manually select signing certificate auch manuell ein solches Zertifikat auswählen, wobei das den Aufwand der Konfiguration deutlich erhöht. Man kann aber auch das gewählte Zertifikat der CA für diesen Zweck verwenden.

Nun muss noch der Revocation Provider angegeben werden. Dabei handelt es sich um die Quelle für die Informationen, die für die Revocation verwendet werden. Hier ist der Pfad zu den Base- und Delta-CRLs der CA anzugeben (Bild 4). Man mag sich im ersten Moment darüber wundern, warum man hier nun CRLs (Certificate Revocation Lists) angeben muss. Immerhin sind CRLs ja genau der Mechanismus, der durch OCSP ersetzt werden soll, weil die mangelnde Aktualität von CRLs ein Sicherheitsrisiko beim Betrieb von zertifikatsbasierenden Infrastrukturen darstellt.

Der entscheidende Punkt ist aber, dass man bei OCSP nun mit kürzeren Intervallen arbeiten kann und das auch machen sollte. Man kann natürlich das Gültigkeitsintervall für CRLS bei der Zertifizierungsstelle unverändert lassen und beim Online Responder die Option Refresh CRL based on its validity period beibehalten. Das ist aber eben nicht die optimale Lösung. Es bietet sich vielmehr an, die CRLs nun sehr häufig publizieren zu lassen oder bei der CA sogar manuell nach der Sperre von Zertifikaten zu erstellen und mit einem kurzen Intervall für die Aktualisierung zu arbeiten. Dieses Intervall wird in dem Dialogfeld auch in Minuten angegeben, was deutlich macht, dass die Idee eben nicht ist, eine Aktualisierung beispielsweise nur einmal pro Tag oder noch seltener durchzuführen. Hier ist es aber wichtig, sowohl bei der Zertifizierungsstelle als auch bei der Konfiguration von OCSP entsprechende Einstellungen vorzunehmen, um wirklich ein höheres Maß an Aktualität zu erreichen. Damit ist die Revocation-Konfiguration abgeschlossen und wird nun in der Liste beim Knoten Revocation Configuration angezeigt.

Array-Konfiguration

Um eine hohe Verfügbarkeit von OCSP zu erreichen, können mehrere Server in einem Array betrieben werden. Standardmäßig findet sich unterhalb von Array Configuration genau ein Server, eben das aktuell verwaltete System. Bei Array Configuration können weitere Systeme mit den OCSP hinzugefügt werden, die dann gleiche Konfigurationen für die Revocation verwenden können. Für die Knoten in einem Array gibt es drei Aktionen:

• Mit Set as Array Controller kann ein System als steuerndes System für ein Array definiert werden. Auf diesem steuernden System werden beispielsweise die Konfigurationsanpassungen durchgeführt.

• Mit Assign Signing Certificate kann das für die Signatur der Nachrichten zu verwendende Zertifikat angegeben werden. Das ist bei der manuellen Festlegung wichtig, kann aber auch erforderlich sein, wenn zwar eigentlich eine automatische Auswahl gewünscht wurde, aber noch kein geeignetes Zertifikat vorhanden war.

• Schließlich kann man sich mit View Provider Properties auch die Einstellungen zu den CRLs für den ausgewählten Provider – also die Zertifizierungsstelle – ansehen und diese bearbeiten.

Damit ist die Konfiguration der OCSP-Infrastruktur abgeschlossen. Soweit die erforderlichen Zertifikate vorhanden sind, können nun OCSPfähige Anwendungen Informationen über die Gültigkeit von digitalen Zertifikaten abfragen. OCSP setzt sich zwar immer mehr durch, aber noch unterstützen bei Weitem nicht alle Anwendungen, die Zertifikate akzeptieren, auch OCSP. Und so manche Anwendung überprüft noch nicht einmal die Gültigkeit von Zertifikaten über die schon lange verfügbaren CRLs.