Optimale Methoden zum Implementieren einer Infrastruktur mit öffentlichem Schlüssel (PKI) unter Microsoft Windows Server 2003

Auf dieser Seite

	Zu diesem Dokument
	Übersicht über den PKI-Entwurfsprozess
	Integration in vorhandene Umgebungen
	Abhängigkeiten der Windows Server 2003-PKI
	Bereitstellungsplanung
	Erstellen von Zertifikatrichtlinien und Verfahrensanweisungen für Zertifikate
	Beispielszenario für die Firma Contoso
	Eigenständige Offline-Zwischenzertifizierungsstelle ("IntermediateCA1")
	Eigenständige Offline-Zwischenzertifizierungsstelle ("CorporateSub2CA")
	Ausstellende Online-Unternehmenszertifizierungsstellen ("CorporateEnt1CA")
	Verwaltung der Zertifizierungsstelle
	Anhang A: Verzeichnisobjekte
	Inhalt von \\Localhost\CertConfig und \\Localhost\CertEnroll
	Beziehung zwischen Konfigurationscontainer und Zertifikatspeicher
	Standardmäßiges CA-Zertifikat und CRL-Speicher
	Zuordnen von benutzerdefinierten Objektkennungen zu Anzeigenamen
	Syntax von "CAPolicy.inf"
	Platzhaltertoken für den CRL-Verteilungspunkt
	CRL-Veröffentlichungseigenschaften
	AIA-Veröffentlichungseigenschaften
	Beispielskript zum Konfigurieren von "CorporateRootCA"
	Beispielskript zum Konfigurieren von "IntermediateCA"
	Beispielskript zum Konfigurieren von "EnterpriseSubCA"
	Anhang B: Parameter für eine dreistufige CA-Topologie
	Anhang C: Weitere Informationen

Zu diesem Dokument

Bei diesem Dokument handelt es sich um einen Leitfaden zum Schnelleinstieg in die Einrichtung einer Infrastruktur mit öffentlichem Schlüssel (Public Key Infrastructure - PKI) unter Microsoft Windows Server 2003. Es enthält sämtliche Informationen, die Sie für die Bereitstellung einer einsatzfähigen PKI auf Basis der Windows Server 2003-Technologie benötigen.

Im vorliegenden Dokument wird eine bewährte PKI-Architektur vorgestellt, die für die meisten Organisationen geeignet ist. Es enthält zudem Tipps sowie optimale Methoden zur Entscheidungsfindung, die sich an den Erfahrungen unserer Kunden orientieren.

Darüber hinaus enthält das Dokument nützliche Prüfanweisungen, damit sichergestellt werden kann, dass alle Konfigurationsschritte ordnungsgemäß durchgeführt wurden. Wo möglich werden zu Vergleichszwecken Informationen zur Installation und Konfiguration eines Servers bereitgestellt, auf dem ein Produkt aus der Produktfamilie Windows 2000 Server ausgeführt wird.

Struktur des Dokuments

Das Dokument basiert auf dem Kapitel Designing a Public Key Infrastruktur (englischsprachig) aus dem Microsoft Windows Server 2003 Deployment Kit, das im Abschnitt Weitere Informationen dieses Dokuments aufgeführt ist. Einige Probleme werden nur in diesem Kapitel des Microsoft Windows Server 2003 Deployment Kits behandelt, während andere nur in diesem Dokument besprochen werden. Durch die ähnliche Dokumentenstruktur wird im Verlauf der Planungs- und Bereitstellungsphase die Navigation vereinfacht, wenn Sie mit allen Dokumenten arbeiten.

Wichtig: Im vorliegenden Dokument werden Features behandelt, die unter Windows Server 2003, Standard Edition, und Windows Server 2003, Enterprise Edition, zur Verfügung stehen. Diese Features stehen jedoch nicht auf Computern unter Windows Server 2003, Web Edition, zur Verfügung.

Umfang

Das Dokument enthält Implementierungsrichtlinien für Administratoren, die eine PKI unter Windows Server 2003 in ihrer Organisation bereitstellen möchten.

Das Whitepaper soll nicht als Einführung in Technologien auf Basis öffentlicher Schlüssel, in Zertifizierungsstellen oder Zertifikate dienen. Es wird davon ausgegangen, dass der Leser über gute Kenntnisse im Hinblick auf die PKI- und Active Directory-Konzepte verfügt.

Da sich das Whitepaper in erster Linie mit der Technologie befasst, werden keine organisationsbezogenen Richtlinien und Regeln besprochen, die für die erfolgreiche Implementierung einer PKI unverzichtbar sind. Sie sollten daher die organisationsbezogenen Anforderungen und optimalen Methoden im Verein mit den Empfehlungen in diesem Whitepaper berücksichtigen, um eine erfolgreiche Bereitstellung zu gewährleisten.

Das Whitepaper umfasst zudem eine Reihe detaillierter optimaler Methoden, die auf praktischen Erfahrungen von Microsoft und Hewlett Packard Consulting Services beruhen.

Weitere Informationen

Das vorliegende Dokument ist eine Erweiterung des Kapitels Designing a Public Key Infrastructure (englischsprachig) aus dem Microsoft Windows Server 2003 Deployment Kit, welches allgemeine Anleitungen zur Planung und zum Entwurf einer PKI enthält, sowie diverser Hilfethemen aus der Windows Server 2003-Hilfe, die Checklisten und Konfigurationsinformationen umfassen. Das vorstehend genannte Kapitel aus dem Microsoft Windows Server 2003 - Handbuch für die Bereitstellung befasst sich im Wesentlichen mit weit gefassten Überlegungen im Hinblick auf die Bereitstellung.

Zum Seitenanfang

Übersicht über den PKI-Entwurfsprozess

Der Entwurf einer PKI umfasst die folgenden Schritte, die jedoch nicht unbedingt in der aufgeführten Reihenfolge durchgeführt werden müssen:

Zum Seitenanfang

Integration in vorhandene Umgebungen

Werden Clientcomputer unter Microsoft Windows 2000 Professional oder Microsoft Windows XP Professional gemeinsam mit Computern verwendet, auf denen ein Produkt aus der Produktfamilie Windows Server 2003 ausgeführt wird, stehen Ihnen zahlreiche Verbesserungen an der PKI zur Verfügung, auf deren Basis Sie Mitarbeitern, Partnern, Kunden und Diensten auf sichere Weise den Zugriff auf Ihr Netzwerk gewähren können. Hiermit werden die Verwaltungsfeatures und das Leistungsspektrum der Windows 2000-Sicherheitsinfrastruktur erheblich verbessert. Windows XP Professional und die Produktfamilie Windows Server 2003 bieten für Organisationen, die auf sichere Geschäftsprozesse und IT-Infrastrukturen angewiesen sind, zahlreiche PKI-spezifische Unternehmensvorteile.

Hierbei wird der Basissatz an Features von der Produktfamilie Windows Server 2003 bereitgestellt, und Server unter Windows Server 2003, Enterprise Edition, und Windows Server 2003, Datacenter Edition, bieten verbesserte Zertifizierungsstellenfunktionen. Bei der PKI, die zum Lieferumfang der Windows Server 2003-Version gehört, handelt es sich um eine verbesserte Version der PKI-Funktionalität von Windows 2000. Dennoch können Sie eine PKI auf Basis von Windows Server 2003 mit einer vorhandenen Active Directory-Umgebung und CA-Infrastruktur auf Basis von Windows 2000 kombinieren.

Für Clientcomputer, auf denen entweder Windows 2000 oder Windows XP als Betriebssystem ausgeführt wird, bietet die Bereitstellung einer Windows Server 2003-PKI die meisten Vorteile, ebenso wie Hardware, die für die Windows-Umgebung ausgelegt ist. Weitere Informationen über die Fähigkeiten der jeweiligen Clientkategorie finden Sie in der Hilfe zu Windows Server 2003.

Ermitteln der Anforderungen für sichere Anwendungen

Windows 2003 Server, Standard Edition, und Windows Server 2003, Enterprise Edition, beinhalten eine umfassende PKI, mit der die Unternehmensvorteile einer Verschlüsselung mit öffentlichen Schlüsseln bereitgestellt werden. Die Fähigkeiten zur Verschlüsselung und zur Signatur sind für Benutzer, Computer und Dienste gleichermaßen von Vorteil.

Die Windows Server 2003-PKI bietet Unterstützung für eine breite Palette von Anwendungen, zu denen auch die folgenden gehören:

Weitere Informationen darüber, wie die Windows-PKI diese Anwendungsbereiche unterstützt, finden Sie in den folgenden Artikel auf der Microsoft-Website:

Die von Windows Server 2003 gebotene PKI-Lösung bietet gegenüber den kommerziellen PKIs von Drittanbieter, die nicht Teil des Betriebssystems sind und separat erworben werden müssen, zahlreiche Vorteile. Benutzer und Zugriffssteuerung werden zentral über Active Directory verwaltet, wodurch der Verwaltungsaufwand für die PKI insgesamt reduziert wird. Darüber hinaus werden für die Windows Server 2003-PKI weder zertifikat- noch benutzergebundene Lizenzgebühren fällig, durch die die Gesamtkosten (Total Cost of Ownership - TCO) eines Systems in die Höhe getrieben werden. Die PKI-Funktionen der Produktfamilie Windows Server 2003 lassen sich zudem hervorragend in viele andere Funktionen des Betriebssystems integrieren.

Zum Seitenanfang

Abhängigkeiten der Windows Server 2003-PKI

Aus technischer Sicht müssen für die Windows Server 2003-PKI einige Anforderungen erfüllt sein, bevor die Infrastruktur implementiert werden kann. Dieser Abschnitt enthält Informationen zur grundlegenden Vorgehensweise sowie Installationsdetails für eine erfolgreiche Implementierung der Windows Server 2003-PKI.

Neue Features eine Windows Server 2003-CA

In Umgebungen unter Windows XP und Windows Server 2003 bieten die Features der Windows Server 2003-Zertifizierungsstelle (CA) die meisten Vorteile, es werden jedoch auch Mischkonfigurationen mit früheren Versionen von Windows unterstützt, wobei jedoch diverse geringfügige Funktionseinschränkungen in Kauf genommen werden müssen.

In der nachstehenden Tabelle werden die Features aufgeführt, die an späterer Stelle in diesem Abschnitt im Detail erläutert werden. Diese Features werden seitens der CA bereitgestellt, sofern die CA unter einer bestimmten Betriebssystemversion installiert wurde.

Tabelle 1. Unterstützung für PKI-Features seitens einer CA, die unter verschiedenen Versionen des Betriebssystems installiert ist

Hinweis: Unter Windows Server 2003, Web Edition, wird zwar die CA-Funktionalität nicht unterstützt, Computer mit diesem Betriebssystem können jedoch als PKI-Client fungieren.

In der folgenden Tabelle werden die Features aufgeführt, die seitens des Clients in einer gegebenen CA-Infrastruktur verwendet werden können.

Tabelle 2. PKI-Features, die auf Clients zur Verfügung stehen

Bild maximieren

Weitere Informationen finden Sie in den folgenden Artikeln:

Vorlagen der Version 2

Vorlagen können als Baupläne für Zertifikate betrachtet werden. Mithilfe einer Vorlage wird eine Zertifikatanforderung in ein Zertifikat umgewandelt, das mit dem privaten Schlüssel der CA signiert ist. Beispielsweise wird mit einer Vorlage die Gültigkeitsdauer eines Zertifikats sowie der Name des Antragstellenden für ein Zertifikat festgelegt.

Der wichtigste Unterschied zwischen Vorlagen der Version 1 (V1) und der Version 2 (V2) besteht darin, dass V1-Vorlagen vordefiniert sind und nicht geändert werden können. Mit V2-Vorlagen kann ein CA-Administrator eine breite Palette von Einstellungen konfigurieren, die im Verlauf der Zertifikatregistrierung angewendet werden. Hierzu gehört die minimale Schlüssellänge, die Definition des Antragstellernamens, Registrierungsanforderungen wie Signatur des Registrierungs-Agenten usw.

V2-Vorlagen stehen nur in Verbindung mit Unternehmenszertifizierungsstellen zur Verfügung, die unter Windows Server 2003, Enterprise Edition, oder Windows Server 2003, Datacenter Edition, ausgeführt werden. V2-Vorlagen werden nicht von Unternehmenszertifizierungsstellen unterstützt, die unter Windows Server 2003, Standard Edition, ausgeführt werden.

Vorlagen werden im Allgemeinen im Active Directory-Konfigurationsnamenskontext gespeichert und können in Verbindung mit jeder CA in einer Active Directory-Gesamtstruktur verwendet werden, sofern sie der CA zugeordnet sind. Für die Nutzung durch alle CAs in der Gesamtstruktur steht ein einziger Satz Vorlagen zur Verfügung. V2-Vorlagen können allerdings nur von CAs unter Windows Server 2003, Enterprise Edition, oder Windows Server 2003, Datacenter Edition, genutzt werden.

Zur Verwendung von V2-Vorlagen muss das Active Directory-Schema auf das Windows Server 2003-Schema in der Gesamtstruktur erweitert werden. Wenn sich die Active Directory-Umgebung nur aus Windows Server 2003-Domänencontrollern zusammensetzt, ist keine weitere Maßnahme erforderlich, um die Windows Server 2003-PKI in vollem Umfang nutzen zu können. Wenn jedoch alle Domänencontroller, die als Hosts für Windows Server 2003-CAs dienen, unter Windows 2000 Server betrieben werden, muss neben den neuen Windows Server 2003-Schemadefinitionen auch Microsoft Windows 2000 Service Pack 3 (SP3) oder höher auf allen Domänencontrollern installiert werden. Weitere Informationen über die Aktualisierung des Schemas finden Sie unter Vorbereiten der Active Directory-Umgebung in diesem Dokument.

Zertifikatregistrierung

Sie können V2-Vorlagen auf jedem Computer, der unter Windows XP oder höher betrieben wird, mit den standardmäßigen Registrierungsmethoden registrieren. Hierzu gehören das Snap-In für Zertifikate der Microsoft Management Console (MMC), der integrierte automatische Registrierungsmechanismus, der Webregistrierungssupport oder Befehlszeilentools.

Bei einem Computer unter Windows 2000 kann das MMC-Snap-In für Zertifikate allerdings nicht zum Registrieren einer V2-Vorlage verwendet werden. Allerdings kann jeder Client, auf dem Microsoft Internet Explorer 5.01 oder höher ausgeführt wird, eine V2-Vorlage zum Registrieren von Zertifikaten mithilfe von Webregistrierungsmethoden sowie einem gedownloadeten ActiveX-Steuerelement verwenden. Damit das ActiveX-Steuerelement auf einen Clientcomputer gedownloadet werden kann, muss die Anmeldung auf dem lokalen Computer als Administrator oder als Hauptbenutzer erfolgen. Daneben können Clients unter Windows 2000 V2-Vorlagen über eine Terminalserververbindung registrieren, sofern der Terminalserver auf einem geeigneten Computer installiert ist, der unter einem Produkt aus der Produktfamilie Windows Server 2003 ausgeführt wird.

Hinweis: Für einen Registrierungs-Agenten, mit dessen Hilfe Zertifikate auf Basis von V2-Vorlagen registriert werden können, ist eine Registrierungsstation unter Windows XP oder Windows Server 2003 erforderlich. Die Registrierung von V2-Vorlagen mit dem Registrierungs-Agenten einer Registrierungsstation unter Windows 2000 wird nicht unterstützt. Allerdings können Zertifikate auf Basis von V2-Vorlagen, die über den Registrierungs-Agenten einer Registrierungsstation unter Windows XP oder Windows Server 2003 registriert wurden, auf einem Clientcomputer unter Windows 2000 verwendet werden.

Wenn Zertifikate für eine Windows 2000-PKI registriert wurden, für die nur V1-Vorlagen zur Verfügung standen, gibt es keinen unmittelbaren Zwang, diese Zertifikate erneut zu registrieren oder durch Zertifikate auf V2-Basis zu ersetzen.

In der folgenden Tabelle werden die unterschiedlichen Registrierungsmethoden aufgeführt, die von Computern unter Windows 2000, Windows XP oder Produkten aus der Windows Server 2003-Produktfamilie unterstützt werden. Mit Unterstützung von CAPICOM und Xenroll kann die Registrierung auch per Skript erfolgen. (Die Dokumentationen zu CAPICOM und Xenroll sowie Beispielanwendungen finden Sie auf der MSDN-Website (Microsoft Developer Network).

Tabelle 3. Zertifikatregistrierung

Hinweis: Da es sich bei der PKI um eine Gesamtstrukturressource handelt, wird die Active Directory-Standortstruktur bei der Anforderung oder Ausgabe einer beliebigen Zertifikatart nicht berücksichtigt. Ein in Active Directory integrierter Zertifikatanforderer listet alle registrierten Registrierungsdienste in Active Directory auf und sendet seine Anforderung an eine CA, bei der der Zertifikattyp registriert werden kann, der vom Benutzer gewünscht wird. Aus der Netzwerkperspektive wird nicht notwendigerweise die am nächsten liegende CA gewählt. Aus diese Grund sollten Sie sicherstellen, dass im Rahmen der CA-Bereitstellung gewährleistet ist, dass jeder Client über eine zuverlässige Netzwerkverbindung zu einer CA verfügt.

Automatische Registrierung von Benutzerzertifikaten

Mit der automatischen Registrierung steht eine schnelle und einfache Methode für die Ausgabe von Benutzerzertifikaten bereit, sodass die Vorteile von Anwendungen, die die PKI nutzen, umfassend ausgeschöpft werden können. Die automatische Registrierung von Benutzern verringert zudem die Bereitstellungskosten für die PKI.

Die automatische Registrierung von Zertifikaten funktioniert auch im Rahmen einer Terminalserversitzung, sofern ein Client verwendet wird, der mit Windows RDP 5.1 (Remote Display-Protokoll) ausgestattet ist.

Wird ein Computer unter Windows XP verwendet, können Benutzer- und Computerzertifikate einschließlich auf Smartcards basierende Zertifikate automatisch registriert werden. Demgegenüber unterstützen Computer unter einem Produkt aus der Windows 2000 Server-Familie nur die automatische Registrierung von Computerzertifikaten. Die automatische Registrierung von Benutzerzertifikaten setzt auf das standardmäßige Windows-Sicherheitsmodell für Domänenauthentifizierung und -autorisierung auf. Dieses Modell ist ggf. nicht für alle Zertifikatausgaben oder Szenarios geeignet.

Unter Verwendung der neuen Autoregistrierungsfunktion können Organisationen den Lebenszyklus von Zertifikaten über V2-Vorlagen für Benutzer verwalten. Hierzu gehört Folgendes:

Abhängig von der Konfiguration der Vorlage, die für die automatische Registrierung verwendet wird, kann der Benutzer benachrichtigt werden, wenn eine Zertifikatregistrierung oder -erneuerung durchgeführt wird.

Die automatische Registrierung von Zertifikaten basiert auf einer Kombination aus Gruppenrichtlinieneinstellungen und V2-Zertifikatvorlagen. Diese Kombination ermöglicht eine zeitlich unabhängige Registrierung und Erneuerung von Computer- und Benutzerzertifikaten im Hintergrund, sofern Gruppenrichtlinien angewendet werden.

Zur Durchführung der Autoregistrierung muss der Zertifikatanforderer entweder als Benutzer oder als Computer in Active Directory registriert und authentifiziert sein.

Weitere Informationen finden Sie unter Certificate Autoenrollment in Windows Server 2003 (englischsprachig) auf der Microsoft TechNet-Website.

Zertifikaterneuerung

Wenn ein Zertifikat das Ende seiner Lebensdauer erreicht hat, muss es erneuert oder ersetzt werden, um sicherzustellen, dass der Eigentümer des Zertifikats diese weiterhin für seine Zwecke nutzen kann.

Bei der Zertifikaterneuerung verfügt der Anfordernde einer Erneuerung bereits über ein Zertifikat. Bei einer Erneuerung des Zertifikats werden bei der Übermittlung der Erneuerungsanforderung die Informationen des vorhandenen Zertifikats berücksichtigt. Ein Zertifikat kann entweder mit einem neuen Schlüssel erneuert werden, oder es kann der vorhandene Schlüssel für das erneuerte Zertifikat verwendet werden.

Wenn ein Zertifikat auf Basis einer V2-Vorlage registriert wurde, kann es nicht auf Basis einer V1-Vorlage erneuert werden. Demgegenüber kann jedoch ein Zertifikat, das auf Basis einer V1-Vorlage registriert wurden, mit einem Zertifikat erneut werden, das aus eine V2-Vorlage erstellt wurde.

Tabelle 4. Zertifikaterneuerung

Schlüsselarchivierung und -wiederherstellung

Die Schlüsselarchivierung und -wiederherstellung ist nur für Verschlüsselungszertifikate auf Basis von V2-Vorlagen möglich, da die Archivierungsoption für jede Vorlage individuell festgelegt werden muss. Die Schlüsselarchivierung wird häufig für Verschlüsselungsschlüssel verwendet, die zum Schutz von permanenten Daten verwendet werden.

Private Schlüssel, die Zertifikaten zugeordnet sind, die lediglich für die digitale Signatur verwendet werden, werden nicht archiviert und von der Zertifizierungsstelle gesperrt. Die Archivierungs- und Wiederherstellungsfunktion, die mit dem Microsoft Exchange 2000-Schlüsselverwaltungsserver (Key Management Server - KMS) bereitgestellt wird, wurde von der Unternehmenszertifizierungsstelle unter Windows Server 2003, Enterprise Edition, ersetzt.

Die Enterprise-Zertifizierungsstelle auf einem Computer unter Windows Server 2003, Enterprise Edition, unterstützt die Migration der Archivdatenbank des Exchange 2000 KMS zur Sicherstellung eines reibungslosen Übergangs zwischen den Technologien.

Das verschlüsselnde Dateisystem (Encrypting File System - EFS) unterstützt daher weiterhin dezentrale Datenwiederherstellungsmethoden ebenso wie die Schlüsselarchivierung auf Clients unter Windows XP.

Deltasperrlisten

Mit Delta-Zertifikatsperrlisten (Certificate Revocation Lists - CRLs) wird der Netzwerkdatenverkehr verringert, der beim Download von neuen Zertifikatsperrlisten zwangsläufig entsteht. Ohne Delta-CRLs muss der Client die Basis-CRL downloaden, die alle Zertifikate enthält, die von einer CA gesperrt wurden. In Delta-CRLs werden nur die Zertifikate aufgeführt, die seit der letzten Veröffentlichung der Basis-CRL gesperrt wurden, um die Größe der CRLs zu verringern und um dafür zu sorgen, dass sich häufigere Aktualisierungen lohnen.

Für Delta-CRLs gelten jedoch einige Beschränkungen:

Weitere Informationen hierüber finden Sie im Artikel Troubleshooting Certificate Status and Revocation auf der Microsoft TechNet-Website.

Qualifizierte Unterordnung

Die qualifizierte Unterordnung ermöglicht die Kreuzzertifizierung von CA-Zertifikaten anhand von Namenseinschränkungen und damit eine präzisere Kontrolle von Zertifikatvertrauensstellungen. Mit der qualifizierten Unterordnung kann der Administrator darüber hinaus auch Zertifikate im Hinblick auf bestimmte Zwecke einschließen oder ausschließen. Beispielsweise kann mit der qualifizierten Unterordnung die Nutzung des IPSec-Protokolls (Internet Protocol Security) in Verbindung mit dem Zertifikat eines Drittanbieters verweigert werden, wohingegen die Nutzung von sicherer E-Mail mit dem gleichen Zertifikat zulässig ist, und zwar auch dann, wenn der Zertifikatschlüssel die Nutzung von IPSec und sicherer E-Mail durchaus zulässt.

Für die qualifizierte Unterordnung wird ein Zertifikatanforderer unter Windows XP oder Windows Server 2003 als Betriebssystem und eine CA unter Windows Server 2003, Enterprise Edition, vorausgesetzt.

Simple Certificate Enrollment-Protokoll

Ein gesichertes Netzwerk kann mit SCEP (Simple Certificate Enrollment-Protokoll) implementiert werden. Das Protokoll wird als Add-On-Komponente mit dem Windows Server 2003 Resource Kit zur Verfügung gestellt. Bei der Komponente Microsoft SCEP (MSCEP) handelt es sich um einen ISAPI-Filter (Internetserver-Anwendungsprogrammierungsschnittstelle), der auf die Microsoft Internetinformationsdienste (IIS) aufsetzt und direkt für eine CA installiert wird, um die Verwendung des Registrierungsprotokolls SCEP in Verbindung mit Netzwerkgeräten zu unterstützen.

Weitere Informationen hierüber finden Sie in Artikel 249125, Using Certificates for Windows 2000 und Cisco IOS Interoperation (maschinelle Übersetzung) in der Microsoft Knowledge Base.

Rollentrennung

Im PKI-Prozess gibt es eine Reihe von Aufgaben, die Sie kennen sollten:

Darüber hinaus gibt es auch eine Reihe von Rollen, die mit der Verwaltung einer Windows Server 2003-CA zusammenhängen, wobei möglicherweise nicht alle Rollen benötigt werden.

In der folgenden Tabelle wird erläutert, welche Rolle eine bestimmte Aufgabe durchführt und welche Berechtigungen zum Durchführen dieser Funktion benötigt werden. Die obere Zeile enthält die verschiedenen Rollen, und in der linken Spalte werden die Aufgabenstellungen aufgeführt. Im Tabellentext werden die Berechtigungen erläutert, die für die Ausführung der jeweiligen Aufgabe erforderlich sind.

Tabelle 5. Rollen und Aufgaben in Verbindung mit Zertifikaten

CA-Berechtigungen

Bei einer eigenständigen Windows Server 2003-CA, die auf einem Server installiert ist, der nicht Mitglied einer Active Directory-Domäne ist, sind für die Verwaltung der CA-Funktionen die Berechtigungen des lokalen Administrators erforderlich.

Bei einem Server, der ein Mitglied der Domäne ist, muss der Benutzer, der eine Unternehmenszertifizierungsstelle installieren möchte, Mitglied der Sicherheitsgruppen Active Directory-Stammdomänenadministratoren und Organisationsadministratoren sein. Sie sollten sicherstellen, dass das Installationskonto Mitglied beider Sicherheitsgruppen ist. Dieser Satz Berechtigungen ist für jede Installation einer Unternehmenszertifizierungsstelle erforderlich, und es wird vorausgesetzt, dass die Gruppe der Organisations-Admins oder die Gruppe der Domänen-Admins zudem auch Mitglied der Gruppe der lokalen Server-Admins ist. Für die Installation einer eigenständigen CA werden lediglich die Rechte eines lokalen Administrators benötigt.

Im Verlauf der Einrichtung werden als Teil des Konfigurationscontainers von Active Directory Container und Objekte erstellt, die Registrierungs- und CA-Informationen enthalten. Eine Liste der von einer CA verwendeten standardmäßigen Objektberechtigungen finden Sie in Artikel 239706, Default Permission Settings for Enterprise Certificate Authority (maschinelle Übersetzung), in der Microsoft Knowledge Base.

Es empfiehlt sich, zum Ändern der Sicherheitsberechtigungen für eine CA das MMC-Snap-In für Zertifizierungsstellen zu verwenden. Die Verwendung anderer Mechanismen wie dem MMC-Snap-In Active Directory-Standorte und -Dienste kann aufgrund von Konfigurationsabweichungen zwischen Active Directory und der lokalen CA-Registrierung eine nicht unterstützte Umgebung zur Folge haben. Mit dem MMC-Snap-In für Zertifikatvorlagen wird die Konsistenz in den Zugriffssteuerungslisten (Access Control Lists - ACLs) sichergestellt. Werden ACLs manuell geändert, fehlen ggf. bestimmte Berechtigungen, und die CA arbeitet dementsprechend nicht erwartungsgemäß.

Verwaltung über Befehlszeilentools

Befehlszeilentools für die Verwaltung gehören zum Lieferumfang der Windows Server 2003-Produktfamilie und können auf Computern unter Windows XP und höher mithilfe der Windows Server 2003-Verwaltungsprogramme installiert werden, die Sie auf dem Installationsdatenträger von Windows Server 2003 finden. Die Befehlszeilentools, die für die CA-Verwaltung unter Betriebssystemen aus der Windows 2000-Produktfamilie erforderlich sind, können nur mit den Windows 2000-Zertifikatdiensten installiert werden. Weitere Informationen über die Programme Certutil.exe und Certreq.exe, eine Beschreibung sowie die erforderliche Syntax finden Sie in der Hilfe zu Windows Server 2003.

CA-Fehlertoleranz

Die Zertifizierungsstellen-Fehlertoleranz sollte generell verwendet werden, denn hiermit wird Folgendes geboten:

Für Online-CAs werden Zertifikatausstellungsdienste bereitgestellt

Für Online- und Offline-CAs werden Informationen zu gesperrten Zertifikaten bereitgestellt

Das native Clustering der CA-Datenbank oder von Zertifikatdiensten wird weder von der Windows 2000-, noch von der Windows Server 2003-Technologie unterstützt. Auf einem Server unter Windows Server 2003 kann immer nur jeweils eine CA-Instanz installiert sein.

Eine Unternehmenszertifizierungsstelle ist so ausgelegt, dass sie in einer Active Directory-Umgebung eine inhärente Fehlertoleranz bietet. Wenn eine Unternehmenszertifizierungsstelle nicht funktioniert oder nicht verfügbar ist, versuchen die Clientdienste automatisch, die Registrierung bei der nächsten verfügbaren Unternehmenszertifizierungsstelle in der Gesamtstruktur durchzuführen. Es werden keine Fehler generiert, und es wird kein Eingreifen seitens des Benutzers erforderlich. Weitere Informationen hierüber finden Sie im Abschnitt Ausstellende Online-Unternehmenszertifizierungsstelle an späterer Stelle in diesem Dokument.

Wenn beispielsweise aufgrund eines Hardwareausfalls keine CA zur Verfügung steht, kann es dennoch weiterhin notwendig sein, regelmäßig die CRL zu veröffentlichen. Das CRL-Veröffentlichungsintervall ist von CA-Konfiguration abhängig. Wenn die CA die CRL nicht rechtzeitig veröffentlicht, können die Clients keine Zertifikate anhand der neuesten Version der CRL prüfen.

Damit eine CRL im Namen einer CA veröffentlicht werden kann, muss sich der Benutzer in Besitz des privaten Schlüssels der CA befinden. Wurde der private Schlüssel der CA in eine Datei exportiert, ist es technisch möglich, eine CRL im Namen einer CA zurückzunehmen und deren Gültigkeitsdauer zu verlängern.

Hinweis: Der Export des privaten Schlüssels der CA in eine Datei kann ein Sicherheitsrisiko darstellen, da der Besitzer dieses privaten Schlüssels im Namen der CA agieren kann. Der private Schlüssel der CA muss äußerst sorgfältig gehütet und an einem sicheren Ort gespeichert werden, der mit sicheren und überwachten Verfahren geschützt wird.

Zum Seitenanfang

Bereitstellungsplanung

Vor der Bereitstellung einer PKI sollte eine sorgfältig definierte Planungsphase durchlaufen werden. Andernfalls kann es passieren, dass die PKI bereits kurz nach der Inbetriebnahme wertlos wird. Zur Vermeidung einer solchen Problematik sollten Sie sicherstellen, dass bei der Bereitstellungsplanung die folgenden Bereiche berücksichtigt werden.

Tabelle 6. Überlegungen bei der Planung einer PKI

Entwerfen der CA-Infrastruktur

Weitere Informationen über die Entscheidung, welche Dienste von den CA-Typen bereitgestellt werden, finden Sie in den folgenden Artikeln auf verschiedenen Microsoft-Websites:

Überlegungen

Es gibt einige wichtige Parameter, die Organisationen beim Start der Planung einer PKI unterstützen können. Aus technischer Sicht gibt es eine Reihe von Schlüsselfaktoren, anhand derer Sie einige grobe Schätzungen vornehmen können:

Die Anzahl der benötigen CAs kann wie folgt geschätzt werden:

Definieren von Zertifizierungsstellentypen und -rollen

Damit Sie die für Ihr Unternehmen geeignete CA-Infrastruktur ordnungsgemäß planen können, müssen Sie die verschiedenen verfügbaren Zertifizierungsstellentypen sowie die Funktionen kennen, die von CAs übernommen werden können.

Der folgende Abschnitt umfasst die wichtigsten Planungsinformationen.

Unternehmenszertifizierungsstellen oder eigenständige Zertifizierungsstellen

Im Rahmen der Zertifikatdienste stehen zwei Zertifizierungsstellentypen bereit, die über einen jeweils unterschiedlichen Funktionsumfang verfügen: Unternehmenszertifizierungsstellen und eigenständige Zertifizierungsstellen. Eine PKI unter Windows Server 2003 kann sich aus beiden Zertifizierungsstellentypen zusammensetzen, was sich in der Unternehmensumgebung oftmals anbietet. Ein Vergleich der Stärken der eigenständigen CA und der Unternehmens-CA kann bei der Entscheidung helfen, welcher CA-Typ für welche Funktion benötigt wird.

Eine eigenständige CA sollte in folgenden Fällen verwendet werden:

Eine Unternehmenszertifizierungsstelle sollte in folgenden Fällen verwendet werden:

Die nachstehende Tabelle enthält eine Übersicht über die bevorzugten Funktionen der beiden Zertifizierungsstellentypen. Je nach CA-Topologie können diese Funktionen von einer geringeren oder einer größeren Anzahl CAs übernommen werden.

Tabelle 7. Zertifizierungsstellentypen und -funktionen

Tabelle 8. Vergleich zwischen eigenständiger und Unternehmenszertifizierungsstelle

Authentifizierung und Autorisierung

Bei eigenständigen CAs wird die lokale Authentifizierung für Zertifikatanforderungen verwendet, in erster Linie über die Webregistrierungsschnittstelle. Mit eigenständigen CAs steht für Dienstanbieter oder kommerzielle PKI-Anbieter eine ideale Plattform für die Ausstellung von Zertifikaten für Benutzer außerhalb der Active Directory-Umgebung bereit, wobei die Identität des Benutzers vor der Übermittlung der Anforderung an die CA separat verifiziert und überprüft wird.

Bei einer CA unter Windows Server 2003, Enterprise Edition, wird DCOM und Kerberos-Identitätswechsel für die Authentifizierung von Anfordernden verwendet. Hierbei wird das Clienttoken anhand einer für die Zertifikatvorlage festgelegten Zugriffssteuerungsliste (ACL) sowie bei der Anforderung des Zertifikats anhand der DCOM-Registrierungsschnittstelle der CA selbst verglichen. Bei einer CA unter Windows 2000 Server wird anstelle von DCOM RPC (Remoteprozeduraufruf) für die Authentifizierung des Anfordernden verwendet. Nachdem der Benutzer authentifiziert und zum Zugriff auf die angeforderte Vorlage berechtigt wurde, kann die Anforderung von der CA unverzüglich verarbeitet werden, sofern der Benutzer über die geeigneten Registrierungsberechtigungen für die Vorlage verfügt und die Konfiguration der CA auf automatische Registrierung festgelegt wurde.

Genehmigung der Zertifikatanforderung

Wenn eine Zertifikatanforderung bei eine CA eingeht, die unter einem Produkt aus der Windows Server 2003-Produktfamilie ausgeführt wird, kann das Zertifikat mit beiden Zertifizierungsstellentypen (Unternehmens-CA und eigenständige CA) unverzüglich ausgestellt oder in den Status "Ausstehend" gesetzt werden. Es liegt in der Zuständigkeit des CA-Administrators, die Registrierungsmethode global für eine CA oder auf Vorlagenbasis zu konfigurieren. Bei einer CA unter Windows 2000 Server ist die Einstellung der Registrierungsmethode nur auf CA-Ebene gültig: alle Zertifikate, die ausgestellt werden, berücksichtigen diese Konfiguration. Bei einer Unternehmens-CA unter Windows Server 2003, Enterprise Edition, kann die Registrierungsmethode individuell für eine V2-Vorlage festgelegt werden.

Bei einer Unternehmens-CA unter Windows 2000 Server gibt es keine Wahlmöglichkeit für die Registrierungsmethode, da Zertifikate hierbei unverzüglich genehmigt und ausgestellt werden. Bei einer eigenständigen CA unter Windows 2000 Server wird die Registrierungsmethode auf CA-Ebene angewendet und kann nicht auf Vorlagenebene festgelegt werden. Dies liegt daran, dass eine CA unter Windows 2000 nur mit V1-Zertifikaten zusammenarbeitet, für die keine Registrierungsberechtigungen vergeben werden können.

Die Standardkonfigurationen für eigenständige CAs sind von den Verwaltungsaktionen sowohl für die Überprüfung der Identität des Anfordernden (auch als Authentifizierung bezeichnet) als auch für die Ausstellung des Zertifikats (auch als Autorisierung bezeichnet) abhängig. Hierbei fungiert der Webregistrierungssupport als Registrierungsstelle (Registration Authority - RA) und die CA als Registrierungsstation. Es ist daher davon abzuraten, eine eigenständige CA für die automatische Ausstellung von Zertifikaten ohne administrative Genehmigung zu konfigurieren, da die Identität des Anfordernden nicht überprüft werden kann. Weitere Informationen über die Zertifikatregistrierung finden Sie im Hilfe- und Supportcenter unter Allowing for Autoenrollment.

Offline- und Online-Zertifizierungsstellen

Die Entscheidung, ob Online- oder Offline-CAs verwendet werden sollen, involviert traditionell einen Kompromiss zwischen Verfügbarkeit und Nutzbarkeit auf der einen und Sicherheit auf der anderen Seite. Je sensibler die Schlüsseldaten und je höher die Sicherheitsanforderungen sind, desto besser sollte die CA gegenüber dem Benutzerzugriff abgeschottet werden.

Wichtig: Aus Sicherheitsgründen sollte eine CA immer auf einem separaten Computer ausgeführt werden. Installieren Sie eine Online-CA niemals auf einem Domänencontroller, auch wenn dies technisch machbar ist.

Wenn eine CA offline betrieben werden soll, gibt es verschiedene Vorgehensweise für physikalische oder technische Schutzmaßnahmen, die im Folgenden beschrieben werden:

Physikalische Schutzmaßnahmen

Technische Schutzmaßnahmen

Die Entscheidung, ob eine CA online oder offline betrieben werden soll, gehört zu den standardmäßigen Funktionsdefinitionen für den Betriebsmodus der CA. Sie können eine eigenständige Offline-CA in eine eigenständige Online-CA umwandeln, wenn Sie diese mit dem Netzwerk verbinden. Jede eigenständige CA, die auf einem Server in einer Arbeitsgruppe ausgeführt wird und mit dem Netzwerk verbunden ist, kann mit einer der vorstehend genannten Vorgehensweisen in eine Offline-CA umgewandelt werden.

Eine eigenständige Stammzertifizierungsstelle wird in der Regel offline geschaltet, da es sich hierbei um einen einzelnen Vertrauensstellungspunkt für die gesamte Organisation oder für mehrere Organisationen handelt. Die Gültigkeitsdauer der Vertrauensstellung ist von der Gültigkeitsdauer des Zertifikats der CA abhängig, sollte jedoch für einen längeren Zeitraum vorgesehen werden. Wenn die Vertrauensstellung einer CA für einen längeren Zeitraum gelten soll, sollten Sie diese CA offline schalten, um weitere Sicherheitsmaßnahmen ergreifen zu können. Auch Zwischenzertifizierungsstellen werden in der Regel als Offline-CAs konfiguriert. Eine Zwischenzertifizierungsstelle ist zwar einer Stammzertifizierungsstelle untergeordnet, dient jedoch auch aus übergeordnete CA für eine oder mehrere andere CAs. Bei diesen CAs kann es sich um ausstellende oder Zwischenzertifizierungsstellen handeln. Bei einer CA mit mindestens drei Schichten ist die Zwischenzertifizierungsstelle die CA auf der mittleren Schicht.

Jede Online-CA setzt Verfügbarkeit und Netzwerkkonnektivität voraus. Bei Online-CAs handelt es sich in der Regel um ausstellende CAs, da ausstellende CAs die Anforderungen von Benutzern, Computern, Diensten und Netzwerkgeräten wie Routern bedienen. Eine Unternehmens-CA muss immer eine Online-CA sein, da hierbei der permanente Zugriff auf Active Directory erforderlich ist, um Konfigurationsinformationen abzurufen, Anforderungen zu überprüfen und Zertifikate zu veröffentlichen. Eine Online-CA bietet naturgemäß mehr Angriffsfläche für Sicherheitsverletzungen.

Hinweis: Als optimale Methode empfiehlt es sich, einen Offline-CA-Server so lange in einem sicheren Vault zu halten, bis ein Zertifikat für eine untergeordnete CA ausgestellt oder eine neue CRL veröffentlicht werden muss.

Hardware-Kryptografieanbieter

Möglicherweise ziehen Sie den Einsatz eines oder mehrerer HSMs in Ihrer PKI-Topologie in Betracht. Bei einem HSM handelt es sich um dedizierte Hardware, die separat vom Betriebssystem verwaltet wird. Diese Module können in Verbindung mit jeder CA unter Windows Server 2003 betrieben werden, um einen sicheren Hardwarespeicher für die CA-Schlüssel bereitzustellen. Aus Sicht des Betriebssystems wird das über die CryptoAPI-Schnittstellen angesteuerte HSM als CSP-Gerät (Cryptographic Service Provide, Kryptografiedienstanbieter) betrachtet.

Mit einem Hardwaresicherheitsmodul ist ein hochgradig sicheres Betriebsmanagement möglich, geschützt durch mehrschichtige Hardware- und Softwaretoken sowie eine Reihe anderer wichtiger Funktionen wie den Folgenden:

Zwar wird mit HSMs die Sicherheit verstärkt, da die Ebene des Schlüsselschutzes erhöht wird, dennoch steht zu beachten, dass hiermit auch die Komplexität und die Kosten der PKI gesteigert werden.

Hardwareschutzmodule, die gut mit Computern unter Windows 2000 Server oder Produkten aus der Windows Server 2003-Produktfamilie zusammenarbeiten, werden von verschiedenen Herstellern angeboten. Weitere Informationen über die Installation von HSMs, die in Verbindung mit Windows-basierten CAs getestet wurden, finden Sie im Abschnitt Installieren eines Hardwaresicherheitsmoduls für eine Offline-Stammzertifizierungsstelle an späterer Stelle in diesem Dokument.

Auswählen eines Vertrauensstellungsmodells

Eine Vertrauensstellung ist eine logische Beziehung, die zwischen Domänen eingerichtet wird, um eine durchgängige Authentifizierung zu ermöglichen, bei der die vertrauende Domäne die Anmeldeauthentifizierungen einer vertrauenswürdigen Domäne akzeptiert. Für Benutzerkonten und globale Gruppen, die in der vertrauenswürdigen Domäne definiert sind, können in der vertrauenden Domäne Rechte und Berechtigungen vergeben werden, und zwar auch dann, wenn die Benutzerkonten und Gruppen im Verzeichnis der vertrauenden Domäne nicht vorhanden sind. Da es sich bei einer CA um den Zertifikatinhaber eines CA-Zertifikats und bei der Endeinheit ggf. um den Zertifikatinhaber eines Benutzerzertifikats handelt ist, ist die Vertrauensstellung zwischen der ausstellenden CA und dem Zertifikatinhaber immer die gleiche. In einer PKI-Stammhierarchie gemäß x.509 wird die Vertrauensstellung abwärts vererbt.

Vertrauensstellungen können zudem über Zertifikatvertrauenslisten und qualifizierte Unterordnung gesteuert werden. (Weitere Informationen enthält die Folienpräsentation Certificate Trust Lists (englischsprachig) auf der Website des National Institute of Standards and Technology (NIST). Die Wahl des geeigneten Vertrauensstellungsmodells kann für den Erfolg einer PKI von ausschlaggebender Bedeutung sein. Eine Organisation muss zudem auch die Anzahl der Schichten in Betracht ziehen, die für die CA-Topologie erforderlich sind. Die Hierarchie kann abwärts erweitert werden, und die Anzahl der CAs, auf einer Ebene verwendet werden, kann anwachsen. Beachten Sie jedoch, dass mit tieferen Strukturen auch die Komplexität der Verwaltung von Vertrauensstellungen in der PKI zunimmt.

Hinweis: Webadressen können sich ändern, daher sind Sie ggf. nicht in der Lage, die Verbindung zu einer oder mehreren der hier aufgeführten Websites herzustellen.

Weitere Informationen hierüber finden Sie im Artikel Trusted Root Certificates That Are Required By Windows 2000 (maschinelle Übersetzung) in der Microsoft Knowledge Base.

Festlegen von Zertifizierungsstellenfunktionen

In einem idealen PKI-Hierarchieentwurf werden die Zuständigkeiten der CAs aufgeteilt. Eine Topologie, die nach Maßgabe eines sorgfältig erarbeiteten Anforderungskatalogs entworfen wird, ermöglicht eine denkbar flexible und skalierbare Unternehmenskonfiguration. Im Allgemeinen sind CAs in Hierarchien organisiert. Einschichtige Hierarchien ermöglichen ggf. keine adäquate Sicherheitsaufteilung und bieten weder Erweiterungsmöglichkeiten noch Flexibilität. Hierarchien mit mehr als drei Schichten bieten hingegen möglicherweise keine zusätzlichen Vorteile im Hinblick auf Sicherheit, Erweiterbarkeit und Flexibilität.

Die wichtigste Überlegung besteht mithin darin, die höchste Instanz der Vertrauensstellung so gut wie möglich zu schützen. Einschichtige Hierarchien tragen der Notwendigkeit Rechnung, die Risiken zu verteilen und die Angriffsfläche für Benutzer mit böswilligen Absichten zu verringern. Eine mehrschichtige Hierarchie ist oftmals schwieriger zu verwalten, wobei die Vorteile im Sicherheitsbereich unerheblich sind.

In Abhängigkeit von den Anforderungen einer Organisation sollte eine PKI aus zwei oder drei logischen Ebenen bestehen, wobei mehrere CAs hierarchisch verknüpft werden. Administratoren, die die Entwurfsvoraussetzungen einer dreischichtigen Topologie überblicken, dürften durchaus in der Lage sein, eine zweischichtige Topologie zu errichten.

Eine dreischichtige CA-Hierarchie setzt sich aus den folgenden Komponenten zusammen:

Abbildung 1. Dreischichtige CA-Hierarchie
Bild maximieren

Für die Einrichtung einer zweischichtigen Topologie führen Sie sämtliche Schritte durch, die an späterer Stelle unter Beispielszenario für die Firma Contoso in diesem Dokument erläutert sind.

Wenn die Sicherheitsanforderungen einer Organisation von einer zweischichtigen Hierarchie erfüllt werden, muss keine dreischichtige Hierarchie eingerichtet werden. Wenn Sie nicht über eine mittlere Schicht verfügen, bezieht sich die CA-Verwaltung auf zwei anstelle von drei Schichten, wodurch die Wartungskosten gesenkt werden.

Gehen Sie zur Implementierung einer zweischichtigen Topologie gemäß den Schritten vor, die in den Abschnitten Eigenständige Offline-Stammzertifizierungsstelle und Ausstellende Online-Unternehmenszertifizierungsstelle (CorporateEnt1CA) in diese Dokument erläutert werden.

Aus technischer Sicht können auch von einer einschichtigen PKI-Hierarchie grundlegende PKI-Dienste bereitgestellt werden. Werden die Stamm- und die Zwischenschicht weggelassen, ergibt sich eine CA, die alles bereitstellen muss. Da die einzelne CA Zertifikate ausstellen muss, kann sie nicht offline geschaltet werden. Bei dieser Art der Implementierung sind Sicherheit und Flexibilität äußerst begrenzt. Wenn Sie eine einschichtige Topologie implementieren möchten, gehen Sie wie unter Ausstellende Online-Unternehmenszertifizierungsstelle (CorporateEnt1CA) beschrieben vor.

Bei der Entscheidung für oder gegen eine separate Stammzertifizierungsstelle für die Ausstellung aller Zertifikate in einer Organisation sollten Sie die Sicherheitsanforderungen gegenüber den Anforderungen im Hinblick auf Kostensenkung und Vereinfachung der Verwaltung abwägen.

Zusammenfassend kann gesagt werden, dass eine zwei- bis vierschichtige CA-Topologie am häufigsten implementiert wird. Jede Organisation sollte in der Lage sein, eine vergleichbare PKI-Architektur zu implementieren, um beliebigen organisatorischen, geschäftlichen und technischen Anforderungen gerecht zu werden und um ein akzeptables Sicherheitsniveau zu schaffen.

Im Hinblick auf Zuverlässigkeit und Redundanz sollte eher die Verfügbarkeit der PKI verbessert werden, indem mehrere Unternehmenszertifizierungsstellen implementiert werden, als dass die Zahl der Hierarchieebenen erhöht würde.

Stammzertifizierungsstellen

Bei einer Stammzertifizierungsstelle handelt es sich um eine selbstsignierte Zertifizierungsstelle. Technisch gesehen wird bei einer Stammzertifizierungsstelle der gleiche Code wie bei einer Zwischen- oder ausstellenden Zertifizierungsstelle ausgeführt. Der Unterschied zwischen diesen CA-Typen besteht in den Funktionen, die die jeweilige CA übernimmt. Die folgende Tabelle enthält eine Liste der Merkmale, die eine Stammzertifizierungsstelle in Abhängigkeit von der Zertifizierungsstellentopologie aufweisen sollte.

Tabelle 9. Merkmal einer Stammzertifizierungsstelle

Auch wenn eine Offline-Stammzertifizierungsstelle ggf. nur ausgeführt wird, wenn ein CA-Zertifikat erneut oder die CRL veröffentlicht werden muss, muss die CA auf zuverlässiger Hardware installiert werden. Wenn Sie ein Notebook für die Übernahme der Funktion der Stammzertifizierungsstelle in Betracht ziehen, beachten Sie, dass ein solches zum Zeitpunkt der Veröffentlichung dieses Dokuments nicht den Anforderungen im Hinblick die gebotene Zuverlässigkeit entspricht.

In den meisten Kundenumgebungen erfordert das Verwalten einer Stammzertifizierungsstelle außerordentliche Sicherheitsmaßnahmen. Die geforderte Sicherheitsebene setzt voraus, dass die Stammzertifizierungsstelle permanent offline geschaltet ist und im Rahmen einer sicheren physikalischen Umgebung geschützt wird. Theoretisch bietet ein Desktopsystem mit Wechselfestplatte ausreichend Schutz für die Stammzertifizierungsstelle.

Zwischenzertifizierungsstellen

Zwischenzertifizierungsstellen sind der Stammzertifizierungsstelle untergeordnet. Bei der Implementierung einer Zwischenzertifizierungsstelle muss die Topologie per Definition aus drei Schichten bestehen. Die Zwischenschicht einer PKI-Hierarchie ermöglicht oftmals eine nützliche Differenzierung von Richtlinien sowie von Verwaltungs- oder operativen Vorgängen. Zwischenzertifizierungsstellen werden auch als Richtlinienzertifizierungsstellen bezeichnet, da sie häufig für die Verwaltung oder Durchsetzung von unterschiedlichen Sicherheits- oder operativen Richtlinien für unterschiedliche geografische Regionen, Geschäftsbereiche oder das Intranet oder Extranet eines Unternehmens herangezogen werden.

Für die Implementierung von Richtlinien ohne Zwischenzertifizierungsstelle können auch den ausstellenden CAs auf logischer Basis Richtlinien zugewiesen werden.

Die Sicherheitsanforderungen einer Zwischenzertifizierungsstelle sind die gleichen wie die der Stammzertifizierungsstelle, da die Zwischenzertifizierungsstelle CA-Zertifikate für ausstellende Online-Zertifizierungsstellen bereitstellt. Bei der Zwischenzertifizierungsstelle sollte es sich um eine eigenständige Offline-Zertifizierungsstelle handeln.

Tipp: Es wird dringend empfohlen, Zertifikate erst dann von einer Zwischenzertifizierungsstelle ausstellen zu lassen, nachdem die Anforderung vom Administrator manuell genehmigt wurde. Dies ist die Standardkonfiguration für eine eigenständige CA unter Windows Server 2003.

Ausstellende CAs

Je nach Architektur kann eine ausstellende CA eine Zwischenzertifizierungsstelle oder einer Stammzertifizierungsstelle untergeordnet sein. Unternehmenszertifizierungsstellen sind ideal für die Ausstellung zahlreicher Zertifikate geeignet, da der Benutzer und die Zertifikatprofilinformationen hiervon automatisch überprüft werden können. Der Zweck einer ausstellenden CA besteht darin, Zertifikate für Endeinheiten und nicht für untergeordnete CAs zu registrieren.

Hinweis: Sie können die Anzahl der untergeordneten CA-Ebenen in einer Zertifikathierarchie begrenzen, indem Sie in der Basiseinschränkungserweiterung eines CA-Zertifikats eine maximale Pfadlänge definieren. Mit einer Pfadlänge von Null wird sichergestellt, dass die ausstellende CA nur Zertifikate für Endeinheiten ausgibt. Die Basiseinschränkungserweiterung und die Pfadlänge können in der Konfigurationsdatei CApolicy.inf definiert werden.

Wissenswertes zu Stammvertrauensstellungen

Wenn ein Client ein Zertifikat verwendet, ist es unabdingbar, dass die Vertrauensstellung zwischen Zertifikat und Stammzertifizierungsstelle überprüft werden kann. Ein Zertifikat wird als vertrauenswürdig angesehen, wenn der Client, der das Zertifikat überprüft, dem Zertifikat der Stammzertifizierungsstelle vertraut, das sich auch im Zertifikatvertrauensstellungspfad des Clients befindet. Der Client muss in seinem lokalen Zertifikatspeicher über das Zertifikat der zugehörigen Stammzertifizierungsstelle verfügen, damit er die Vertrauensstellung zur Stammzertifizierungsstelle prüfen kann. Weitere Informationen finden Sie unter Policies to establish trust of root certification authorities (englischsprachig) auf der Microsoft-Website.

Wenn mit Active Directory gearbeitet wird, ist es wichtig zu verstehen, wie Clients wie Benutzer oder Computer die Vorteile von Active Directory nutzen können, um eine Vertrauensstellung zur Stammzertifizierungsstelle einzurichten.

Sie können eine Vertrauensstellung einrichten, die von einer Stammzertifizierungsstelle abgeleitet wird, indem Sie das Zertifikat der Stammzertifizierungsstelle mit einer der folgenden sechs Methoden implementieren:

In Abhängigkeit von den Berechtigungen und der Reichweite des Verteilungsmechanismus werden Zertifikate an unterschiedlichen Standorten abgelegt und setzen unterschiedliche Verwaltungstools voraus. Weitere Informationen finden Sie in der folgenden Tabelle.

Tabelle 10. Mechanismen für Zertifikatvertrauensstellungen

Unternehmensvertrauen

Für den automatischen Download von Zertifikaten der Stammzertifizierungsstelle und von Zertifikatvertrauenslisten aus dem Active Directory-Speicher für Unternehmensvertrauen auf Clients unter Windows 2000 und Windows XP kann der integrierte automatische Registrierungsdienst verwendet werden.

Weitere Informationen finden Sie in den folgenden Artikeln auf der Microsoft-Website:

Gruppenrichtlinienvertrauensstellung

Eine Gruppenrichtlinienvertrauensstellung wird unter Verwendung des MMC-Snap-Ins für Gruppenrichtlinien und des standardmäßigen Domänen-Gruppenrichtlinienobjekts konfiguriert. Eine Gruppenrichtlinienvertrauensstellung wird für die Domäne konfiguriert und durchgesetzt, auf die das Gruppenrichtlinienobjekt angewendet wird. Aus diesem Grund verfügen unterschiedliche Benutzer in unterschiedlichen Domänen über Vertrauensstellungen zu unterschiedlichen Stammzertifizierungsstellen. Es wird dringend empfohlen, eine neue Domänenrichtlinie zu erstellen, anstatt die standardmäßigen Domänenrichtlinien zu bearbeiten.

Hinweis: Clientcomputer müssen nur den Zertifikaten der Stammzertifizierungsstelle vertrauen und nur diese registrieren. Sie sollten der Gruppenrichtlinienvertrauensstellung keine Zertifikate von untergeordneten Zertifizierungsstellen hinzufügen, da den Zertifikaten von Zwischenzertifizierungsstellen und ausstellenden Zertifizierungsstellen ggf. nicht explizit vertraut wird. Die CryptoAPI erstellt mit der Erweiterung des Stelleninformationszugriffs (Authority Information Access - AIA) automatisch Zertifikatsketten für die Zertifikate von untergeordneten und Zwischenzertifizierungsstellen.

NTAuth

Der NTAuth-Speicher wird aus der Konfigurationspartition der Gesamtstruktur auf allen Computern in der Gesamtstruktur im folgenden Verzeichnispfad bereitgestellt:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Wichtig: NTAuth-CAs verfügen über die erforderliche Vertrauensstellung, um sowohl Authentifizierungszertifikate (Anmeldungszertifikate) für jeden Benutzer in der Gesamtstruktur auszustellen, als auch die Anmeldung per Smartcard, IIS-Zuordnung (Internetinformationsdienste) und EAP-TLS (Extensible Authentication Protokoll-Transport Layer Security) zu ermöglichen. Eine präzise Steuerung der ausstellenden CA kann durch eine qualifizierte Unterordnung mit Beschränkungen erreicht werden.

Sie können die Zertifikate überprüfen, die aktuell in NTAuth registriert sind, indem Sie den folgenden Befehl an der Eingabeaufforderung eingeben, wobei die Informationen zur Domänenkomponente mit dem Namen der Active Directory-Stammdomäne konfiguriert sind:

certutil.exe -store ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

Eine eher visuell orientierte Anzeige der Zertifikate erhalten Sie, wenn Sie Folgendes an der Befehlseingabeaufforderung eingeben:

certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC="

Darüber hinaus kann der NTAuth-Speicher auch manuell verwaltet werden, indem einer der folgenden Befehle an der Eingabeaufforderung eingegeben wird:

certutil -addstore
certutil -delstore
certutil -dspublishZertifikatDateiNTAuth

Weitere Informationen über den NTAuth-Speicher und die Anmeldung per Smartcard finden Sie in den folgenden Artikel auf diversen Microsoft-Websites:

In einer Active Directory-Umgebung unter Windows Server 2003, die lediglich Clients unter Windows XP enthält, ist der NTAuth-Speicher für die Anmeldung per Smartcard und die Zertifikatzuordnung nicht zwingend erforderlich, ganz im Gegensatz zu einer gemischten Umgebung unter Windows Server 2003 mit Clients unter Windows 2000. Da Active Directory unter Windows Server 2003 die Veröffentlichung von Kreuzzertifikaten unterstützt und da Clients unter Windows XP Namens- und Richtlinieneinschränkungen für x.509-Zertifikate unterstützen, können Administratoren in homogenen Umgebungen unter Windows Server 2003 und unter Windows XP auf die NTAuth-Richtlinie verzichten. Diese Option setzt voraus und geht davon aus, dass CAs über definierte Namenseinschränkungen verfügen, anstatt im NTAuth-Speicher des Verzeichnisses aufgeführt zu sein. Daher vertrauen Domänencontroller, die sowohl die Anmeldung per Smartcard als auch Zertifikatzuordnungsanforderungen verarbeiten, explizit alle CAs, die mit vertrauenswürdigen Stammzertifizierungsstellen verkettet sind, und zwar unter der Annahme, dass das Zertifikat einem gültigen Benutzerkonto in Active Directory entspricht.

Achtung: Wenn die NTAuth-Richtlinienüberprüfung deaktiviert wird, werden Domänencontrollervertrauensstellungen von beliebigen CAs aktiviert, die gültige Smartcard-Anmeldezertifikate ausstellen und eine Verkettung zu einer vertrauenswürdigen Stammzertifizierungsstelle in der Active Directory-Umgebung herstellen. Für sämtliche CAs, also auch für standardmäßige Stammzertifizierungsstellen von Drittanbietern, sollten Namenseinschränkungen definiert werden, bevor die NTAuth-Richtlinie deaktiviert wird. Wenn dies nicht erfolgt, können unerwünschte Vertrauensstellungen und Anmeldezugriffe die Folge sein. Verwenden Sie diese Option mit äußerster Vorsicht und nur dann, wenn die Stammzertifizierungsstellen in der Umgebung ordnungsgemäß eingeschränkt wurden.

Weitere Informationen zur qualifizierten Unterordnung und zu Namenseinschränkungen finden Sie unter Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 (englischsprachig) auf der Microsoft TechNet-Website.

Manuelle Vertrauensstellung auf einem lokalen Computer

Vertrauensstellungen für die Zertifikate von Stammzertifizierungsstellen können auf einem lokalen Computer auch manuell unter der Verwendung des MMC-Snap-Ins für Zertifikate eingerichtet werden. Hierfür muss der Benutzer allerdings als lokaler Administrator angemeldet sein, damit er dem Zertifikatsspeicher des Computers Zertifikate der Stammzertifizierungsstelle hinzufügen kann. Sämtliche Zertifikate der Stammzertifizierungsstelle im Zertifikatspeicher des Computers werden an alle Benutzer vererbt, die sich an diesem Computer anmelden. Aus Sicht des Benutzers bilden der Speicher für vertrauenswürdige Stammzertifikate des Benutzers und der Speicher für vertrauenswürdige Stammzertifikate des Computers eine Einheit.

Weitere Informationen über Zertifikatspeicher finden Sie in Kapitel 13, Public Key Technology (englischsprachig), auf der Website zum Windows 2000 Resource Kit.

Vergewissern Sie sich, dass alle Zertifikate im ordnungsgemäßen Pfad gespeichert sind. Jedes Zertifikat der Stammzertifizierungsstelle, das im Zertifikatspeicher des lokalen Computers gespeichert ist, ist für jeden Benutzer dieses Computers sichtbar. Wenn ein Zertifikat der Stammzertifizierungsstelle im Speicher des lokalen Computers registriert ist und dieses Zertifikat zudem von einem Benutzer manuell hinzugefügt wird, wird das Zertifikat der Stammzertifizierungsstelle im MMC-Snap-In für Zertifikate ggf. zwei Mal angezeigt. Wenn ein Stammzertifikat nicht im Zertifikatspeicher des lokalen Computers, jedoch im Speicher des Benutzers verfügbar ist, funktioniert zudem der Aufbau einer Zertifikatkette für einige Anwendungen möglicherweise nicht.

Sie können den Zertifikatspeicher eines Computers auch mit dem Internet Explorer Administration Kit (IEAK) oder mit CAPICOM verwalten. Weitere Informationen über CAPICOM finden Sie im Artikel CAPICOM Reference (englischsprachig) auf der MSDN-Website.

Manuelle Vertrauensstellung durch Benutzer

Es empfiehlt sich, Zertifikatvertrauensstellungen nur von Administrator verwalten zu lassen und nur CA-Zertifikate im Zertifikatspeicher des lokalen Computers zu speichern.

Windows Update

Standardmäßig wird auf Computern unter Windows XP und unter Produkten der Windows Server 2003-Produktfamilie ein Dienst ausgeführt, mit dem aktualisierte Zertifikate der öffentlichen Stammzertifizierungsstelle gedownloadet werden, die dem Microsoft-Stammprogramm hinzugefügt wurden. Dieser Dienst steht bei Produkten aus der Windows 2000-Produktfamilie nicht zur Verfügung.

Jede Organisation, die über eine Zertifizierungsstelle verfügt und den im Microsoft Root Certificate-Programm erläuterten Anforderungen entspricht, kann das CA-Zertifikat über Windows Update verteilen. Weitere Informationen hierüber finden Sie unter Microsoft Root Certificate Program (englischsprachig) auf der Microsoft TechNet-Website.

Computer, auf denen entweder Windows XP oder Windows Server 2003 ausgeführt wird, downloaden regelmäßig die aktuelle Liste der Zertifikate der Stammzertifizierungsstelle, die dann dem Autorisierungsspeicher für Drittanbieter-Stammzertifizierungen auf dem lokalen Computer hinzugefügt werden. Weitere Informationen hierüber finden Sie im Kapitel Certificate support and the Update Root Certificates component in Dokument Using Windows XP Professional with Service Pack 1 in a Managed Environment: Controlling Communication with the Internet (englischsprachig), das auf der Microsoft-Website zum Download bereitsteht.

Zum Installieren oder Entfernen dieses Dienstes können Sie die Option Software aus der Systemsteuerung verwenden. Klicken Sie hierzu auf die Schaltfläche Start, zeigen Sie auf Systemsteuerung, und klicken Sie dann auf Software. Klicken Sie auf der Symbolleiste auf Windows-Komponenten hinzufügen/entfernen, und aktivieren Sie dann unter Komponenten das Kontrollkästchen Aktualisierung von Stammzertifikaten.

Dieser Dienst kann auch über Gruppenrichtlinien in Active Directory verwaltet werden.

Abbildung 2. Assistent für Windows-Komponenten
Bild maximieren

Entwerfen einer Registrierungsstrategie

Ein Zertifikat kann verwendet werden, um den Inhaber zu authentifizieren oder um Daten zu verschlüsseln oder zu signieren. Aus diesem Grund muss der Aussteller des Zertifikats sicherstellen, dass es sich bei den Zertifikatinhabern um bekannte Einheiten handelt. Bevor Zertifikate registriert werden, sollten Sie die folgenden Fragen beantworten:

Die sicherste Methode für die Erstregistrierung von Benutzerzertifikaten besteht darin, eine persönliche Authentifizierung der Person in der Registrierungsstelle vorzunehmen und die Benutzerzertifikate in Hardwaretoken zu speichern. Diese Vorgehensweise bietet zwar das höchste Sicherheitsniveau, bringt aber auch die höchsten Bereitstellungskosten mit sich.

Wenn die Zertifikatregistrierung mit Hardwaretoken über Registrierungs-Agenten nicht möglich ist, kann die CA den Zertifikatanforderer anhand von Domänenanmeldeinformationen überprüfen. Diese Authentifizierungsmethode für die Zertifikatregistrierung wird in der Regel verwendet, wenn Benutzer Zertifikate selbst registrieren. In diesem Szenario wird davon ausgegangen, dass der Benutzer als einzige Person mit diesen Anmeldeinformationen arbeiten kann.

Es empfiehlt sich daher, eine kombinierte Registrierungsstrategie zu verwenden, bei der eine starke erste Identitätsprüfung erfolgt. Die nachfolgende Zertifikatregistrierung und -erneuerung kann dann auf dem ersten Zertifikat basieren.

Entwerfen einer Erneuerungsstrategie für Zertifikate

Die Gültigkeitsdauer von Zertifikaten kann aus folgenden Gründen Einfluss auf die Sicherheit der PKI nehmen:

Die Zertifikate von Endeinheiten laufen ab, wenn die Gültigkeitsdauer des Zertifikats der ausstellenden Zertifizierungsstelle abläuft, sofern nicht Folgendes eintritt:

Die Erneuerung von CA-Zertifikaten muss im Verlauf der PKI-Bereitstellungsphase präzise geplant werden. Wenn dieser wichtige Planungsschritt unterbleibt, stellt bei Ablauf des CA-Zertifikats möglicherweise die gesamte PKI die Arbeit ein, da alle Zertifikate, die auf dem Zertifikat der Zertifizierungsstelle basieren, im Weiteren weder für die Verschlüsselung noch für die Signierung verwendet werden können. Denken Sie jedoch daran, dass ein Zertifikat auch dann zum Entschlüsseln von Daten verwendet werden kann, wenn es abgelaufen ist oder gesperrt wurde.

Hinweis: Es wird dringend empfohlen, neue Schlüsseldaten zu generieren, wenn Sie das Zertifikat einer Zertifizierungsstelle erneuern, um die CRL zu partitionieren, die von der Zertifizierungsstelle ausgegeben wird, und um zudem zu verhindern, dass durch die Verwendung des gleichen öffentlichen Schlüssels unklare Zertifikatverkettungsfehler auftreten.

Ermitteln der Gesamtanzahl benötigter CAs

Die Gesamtanzahl benötigter CAs ist von den Sicherheitsanforderungen der Organisation und von deren Größe abhängig. Darüber hinaus ist auch die geografische, politische und geschäftliche Hierarchie der Organisation ausschlaggebend. Wie bereits an früherer Stelle in diesem Dokument erläutert, gibt es eine Auswahl verschiedener Vertrauensstellungsebenen, die angewendet werden können. Nachdem die Organisation die Anzahl der zu implementierenden hierarchischen Schichten festgelegt hat, muss unbedingt die Anzahl der CAs geplant werden, die auf jeder Schicht benötigt werden. Bei einer PKI-Topologie mit Zwischenzertifizierungsstellen ist die Anzahl der CAs von der Anzahl der unterschiedlichen CA-Richtlinien abhängig, die bei der Ausstellung von Zertifikaten berücksichtigt werden sollen. Die Anzahl der ausstellenden CAs ist von der Anzahl der Zertifikate abhängig, die ausgestellt werden sollen, von der Netzwerkverbindung zwischen Anforderndem und der CA sowie von der Anzahl der Zwischenzertifizierungsstellen.

Eine dreischichtige Architektur besteht aus folgenden Komponenten:

Eine zweischichtige Architektur besteht aus folgenden Komponenten:

Beachten Sie Folgendes:

Bei extern verwendeten Zertifikaten sollte anhand des Namens und der Informationen, die Bestandteil der Zertifikate sind, nicht die interne PKI- oder Netzwerkinfrastruktur abgeleitet werden können, d. h. Angaben wie Name der Zertifizierungsstelle oder Pfade zu Sperrlisten-Verteilungspunkten sollten in ausgestellten Zertifikaten nicht enthalten sein.

Hardwareanforderungen

Dieser Abschnitt enthält einige allgemeine Richtlinien betreffend die Hardwareanforderungen für eine CA unter Windows Server 2003. Der Abschnitt sollte jedoch nicht als maßgebliche Richtschnur für Leistungsmerkmale verstanden werden. Je nach Implementierung und Kundenumgebung können bestimmte Leistungsmerkmale unterschiedlich sein.

Richtlinien im Hinblick auf die Hardware

Anhand von Leistungstests, die bei Microsoft in einer Laborumgebung durchgeführt wurden, hat sich herausgestellt, dass die Länge des Signaturschlüssels der CA die signifikantesten Auswirkungen auf die Registrierungsrate der CA hat. Wenn eine geringere Schlüssellänge verwendet wird, kann innerhalb eines gegebenen Zeitraums eine größere Anzahl Zertifikate signiert und registriert werden. Wird eine größere Schlüssellänge verwendet, ist für die Ausstellung von Zertifikaten mehr CPU-Zeit erforderlich.

Die Gesamtanzahl der ausgestellten Zertifikate sollte keinen wesentlichen Einfluss haben, weder auf die Serverleistung noch auf die Rate, mit der von der CA Zertifikate ausgestellt werden; die Leistung der ausstellenden CA bleibt annähernd die gleiche, ungeachtet, ob im Vorfeld Tausende oder Millionen Zertifikate ausgestellt wurden. Daher wird die Skalierbarkeit der CA basierend auf der Größe und Leistungsfähigkeit der Festplattenarrays, die zum Speichern der Datenbank und der Protokolldateien verwendet werden, als linear angesehen.

Die nachstehende Tabelle enthält die Konfigurationsfaktoren, die die Leistungsfähigkeit der CA ggf. beeinflussen können.

Tabelle 11. Ressourcen, die Einfluss auf die Leistungsfähigkeit der CA haben

Hinweise zum Prozessor

Im Allgemeinen wird ein Computer, der mit einem zeitgemäßen Prozessor und 512 MB Arbeitsspeicher ausgestattet ist, für die meisten Einsatzbereiche einer CA unter Windows Server 2003 in Organisationen als ausreichend betrachtet. Die Registrierungsrate steht in direkter Beziehung zur Fähigkeit der CA, Anforderungen zu signieren, was wiederum auf der Verfügbarkeit der CPU basiert. Die Leistungsfähigkeit einer CA kann von vielen Faktoren wie Hardware Umgebung, Netzwerk oder verwendeter Client beeinflusst werden.

Hinweise zur Datenträgerkonfiguration

Leistungsfähigkeit und Skalierbarkeit einer CA werden auch vom Festplattenspeicher und von der Festplattengeschwindigkeit begrenzt. Für jedes ausgestellte Zertifikat werden seitens der Datenbank ca. 16 KB Speicherplatz benötigt; hinzu kommen weitere 4 KB, wenn der private Schlüssel archiviert wird. Die Zertifikatdatenbank muss alle ausgestellten Zertifikate enthalten, damit Zertifikate gesperrt und Datensätze der Vorgänge erstellt werden können. Da keiner dieser Datensätze jemals automatisch als veraltet gekennzeichnet oder gelöscht wird, steigt die Größe der Zertifikatdatenbank kontinuierlich an, wenn neue Zertifikate ausgestellt werden. Der CA-Administrator kann jedoch mithilfe des Befehlszeilentools Certutil.exe abgelaufene Datensätze aus der CA-Datenbank löschen.

Skalierbarkeit

Mit einer CA unter Windows 2000 wurden im Test mehr als 7 Millionen Zertifikate ausgestellt, und mit einer CA unter Windows Server 2003 wurde im Test mehr als 35 Millionen Zertifikate ausgestellt. Für die Tests wurde ein einziger auf Intel basierenden Computer mit vier Prozessoren verwendet. In keinem der Testszenarios wurde die maximale Datenbankgröße erreicht.

Zum Seitenanfang

Erstellen von Zertifikatrichtlinien und Verfahrensanweisungen für Zertifikate

Die Definition von Zertifikatrichtlinien und der Zertifikatverwendungserklärung (Certificate Practice Statement - CPS) wird von technisch orientierten Planern häufig vergessen. Die Basis für die Zertifikatrichtlinie und die CPS bilden die Sicherheitsrichtlinien der Organisation.

Die Erstellung dieser Dokumente liegt in der Regel in der gemeinsamen Zuständigkeit der Rechtsabteilung, der Personalabteilung und der Abteilung für Datensicherheit.

Abbildung 3. Beziehung zwischen Zertifikatrichtlinie und Verfahrensanweisung für Zertifikate

Sowohl die Zertifikatrichtlinie als auch die CPS helfen dem Benutzer einer PKI, die Vertrauensstellungsebene festzustellen, mit der diese Abteilungen die Zertifikate ausstatten, die von einer CA ausgestellt werden. Das Vorhandensein von Richtlinien ist für eine zuverlässige PKI von ausschlaggebender Bedeutung. Wenn Zertifikate nur innerhalb einer Organisation ausgetauscht werden, ist die Erstellung einer CPS und einer Sicherheitsrichtlinie ggf. nicht obligatorisch. Wenn dies zutrifft, könnten jedoch einige Klauseln betreffend die Verwendung der PKI und von Zertifikaten in einem Mitarbeiterleitfaden notwendig werden. Bitte beachten Sie, dass es sich bei einer organisationseigenen CPS um eine CPS handelt, die alle CAs in der Hierarchie einbezieht. Im Allgemeinen bezieht sich eine CPS allerdings nur auf eine bestimmte CA.

Verfahrensweisen für Zertifikate und Verfahrensanweisungen für Zertifikate könnte sich als erforderlich erweisen, wenn die Zertifikatinhaber Zertifikate in Verbindung mit Partnern und Einheiten verwenden oder austauschen, die sich außerhalb des Unternehmensnetzwerkes befinden. Werden externe Vertrauensstellungen implementiert, ist es oftmals äußerst wichtig, die PKI-Richtlinien und -Verfahrensweisen als Bestandteil der Bedingungen externer Verträge anzugleichen.

Sicherheitsrichtlinie

Die Sicherheitsrichtlinie ist ein äußerst wichtiges Dokument, das von der IT-Gruppe eines Unternehmens erstellt wird. Hierin werden Regeln im Hinblick auf die Nutzung und Bereitstellung von Sicherheitsdiensten in der Organisation definiert, und es sollte die Geschäfts- und IT-Strategien einer Organisation widerspiegeln. Die Sicherheitsrichtlinie sollte übergeordnete Fragen betreffend die PKI beantworten, wozu auch die folgenden gehören:

Zertifikatrichtlinie

Eine Zertifikatrichtlinie bezieht sich im Wesentlichen auf Zertifikate sowie die Zuständigkeiten der CAs im Hinblick auf diese Zertifikate. Hierin werden Zertifikatmerkmale wie Nutzung-, Registrierungs- und Ausstellungsverfahren sowie Problemstellungen im Hinblick auf Haftungsfragen definiert.

In den folgenden Verweisen wird eine Zertifikatrichtlinie als Sammlung von Regeln definiert, mit denen festgelegt wird, ob ein Zertifikat für eine Benutzergemeinschaft oder eine Anwendungsklasse gilt, die gemeinsame Sicherheitsanforderungen aufweisen.

Weitere Informationen über den Standard X.509 finden Sie auf der Website der International Telecommunication Union.

Weitere Informationen über die Definition der EESSI (European Electronic Signature Standardization Initiative) finden Sie auf der EESSI-Website.

Mit einer Zertifikatrichtlinie wird normalerweise die Frage beantwortet, welchem Zweck das Zertifikat dient und unter welchen Richtlinien und Verfahren das Zertifikat ausgestellt wurde. Eine Zertifikatrichtlinie befasst sich in der Regel mit den folgenden Problemstellungen:

Die Zertifikatrichtlinie wird in der Regel von den Mitgliedern einer Organisation definiert, die als Richtlinienautorität bezeichnet wird. Diese Richtlinienautorität setzt sich normalerweise aus Repräsentanten unterschiedlicher Abteilungen zusammen, wozu das Management ebenso gehört wie die Rechtsabteilung, die Qualitätssicherung, die Personalabteilung u. a. m. Insgesamt gesehen sind die Mitglieder der Richtlinienautorität zudem Mitglieder der Gruppe, die die Sicherheitsrichtlinie definiert hat, wodurch sichergestellt wird, dass die Zertifikatrichtlinie mit der Sicherheitsrichtlinie übereinstimmt.

Verfahrensanweisungen für Zertifikate

Mit der Zertifikatverwendungserklärung (Certificate Practice Statement - CPS) werden die Zertifikatrichtlinien in operative Verfahren auf CA-Ebene umgewandelt. Hierbei befasst sich die Zertifikatrichtlinie mit einem Zertifikat und die CPS mit einer CA. Sowohl die EESSI als auch die American Bar Association (ABA) definieren eine CPS als eine Anweisung betreffend die Methode, mit der eine CA Zertifikate ausstellt. Weitere Informationen über die ABA finden Sie auf der ABA-Website. Weitere Informationen über die EESSI finden Sie auf der EESSI-Website.

Eine CPS kann die folgenden Informationen umfassen:

Die CPS sollte von einem Team definiert werden, das sich aus Mitgliedern der IT-Abteilung, aus Personen aus dem operativen und dem Verwaltungsbereich der IT-Infrastruktur sowie Personen zusammensetzt, die die Zertifikatrichtlinie definiert haben (häufig Rechtsexperten). Bei der CPS handelt es sich um ein öffentliches Dokument, das im Internet publiziert werden sollte. Jedes Zertifikat, das von einer CA ausgestellt wurde, die sich auf eine CPS bezieht, verfügt über einen URL-Verweis im Zertifikat, über den dieses öffentliche Dokument angezeigt werden kann. Wenn ein Zertifikat über einen CPS-Verweis verfügt, steht die Schaltfläche Ausstellererklärung zur Verfügung. Wenn Sie auf die Schaltfläche Ausstellererklärung klicken, wird der URL, der vom CA-Administrator festgelegt wurde, umgeleitet.

Wichtig: Eine CPS gilt auch immer für alle Zertifikate, die einer der CA, die den Kennzeichner enthält, untergeordneten CA ausgestellt wurden. Vergewissern Sie sich, dass alle in Anhang B aufgeführten Parameter Bestandteil des Planungsprozesses sind.

Sperrungsrichtlinien

Bevor Zertifikate registriert werden, sollte das PKI-Verwaltungsteam wissen, wie Zertifikate gesperrt werden. Jedes X.509 V3-Zertifikat (außer dem Zertifikat der Stammzertifizierungsstelle als solchem) sollte einen Verweis auf eine gültige CRL enthalten. Der Sperrlisten-Verteilungspunkt wird in die Erweiterung des Zertifikats eingeschlossen und kann nach dessen Registrierung nicht mehr geändert werden.

Die logische Verfügbarkeit des Sperrlisten-Verteilungspunktes, der im Zertifikat angegeben ist, ermöglicht einer für PKI aktivierten Anwendung, die Gültigkeit des Zertifikats anhand der CRL zu prüfen. Die CRL ist von ausschlaggebender Bedeutung, um die Qualität (den Status) von Zertifikaten sicherzustellen, die von der CA veröffentlicht werden. Wenn die CRL verfügbar und sich die Seriennummer des Zertifikats in der CRL befindet, wird das Zertifikat aus der Perspektive eines Clients als ungültig gekennzeichnet.

Die Seriennummer eines gesperrten Zertifikats wird der CRL hinzugefügt, sofern die Gültigkeitsdauer des ursprünglichen Zertifikats noch nicht abgelaufen ist. Sobald die ursprüngliche Gültigkeitsdauer des Zertifikats abgelaufen ist, wird dessen Seriennummer der CRL zum letzten Mal hinzugefügt.

Hinweis: Gesperrte Zertifikate können nicht mehr zum Signieren oder Verschlüsseln verwendet werden. Sie können gesperrte Zertifikate jedoch noch zum Entschlüsseln verwenden, da die hiermit verschlüsselten Dateien ansonsten nicht mehr entschlüsselt werden könnten.

Wenn ein Zertifikat von einer Anwendung anhand der CRL geprüft werden soll, jedoch keine gültige CRL verfügbar ist, funktioniert die Sperrungsprüfung nicht, und das Zertifikat kann nicht für die Transaktion verwendet werden. Wenn die CRL-Prüfung in der Anwendung ordnungsgemäß implementiert wurde, ist erst dann wieder eine Authentifizierung, Verschlüsselung oder Signatur mit diesem Zertifikat möglich, wenn eine gültige CRL verfügbar ist.

Wenn Anmeldezertifikate unverzüglich gesperrt werden sollen, können Sie ggf. auch das Konto in Active Directory deaktivieren, anstatt das Anmeldezertifikat zu sperren. Wenn der Zugriff des Benutzers auf die Anmeldezertifikate unverzüglich gesperrt werden soll, geht es schneller, das Benutzerkonto zu löschen oder zu deaktivieren.

Weitere Informationen über CRLs, AIA und den Aufbau von Zertifikatsketten finden Sie im Whitepaper Troubleshooting Certificate Status and Revocation (englischsprachig) auf der Microsoft TechNet-Website.

Optimale Methoden in Verbindung mit CRLs

Bei der Planung der CRL-Verteilung sollten Sie wissen, wo und wie Clients auf eine CRL zugreifen. Die CRL-Verteilungsmechanismen sind standardmäßig für Unternehmenszertifizierungsstellen und eigenständige Zertifizierungsstellen unterschiedlich.

Es wird häufig der Fehler gemacht, dass der standardmäßige Sperrlisten-Verteilungspunkt einer isolierten eigenständigen CA nicht geändert wird. Da eine Stamm- oder Zwischenzertifizierungsstelle in der Regel nicht mit dem Netzwerk verbunden ist, können für PKI aktivierte Clients die ausgestellten Zertifikate nicht anhand des standardmäßigen Sperrlisten-Verteilungspunktes auf dem CA-Server prüfen. Wenn Sie die CRL einer eigenständigen Offline-CA öffentlich verfügbar machen möchten, müssen Sie die CRL manuell veröffentlichen oder ein benutzerdefiniertes Beendigungsmodul oder Skript verwenden, mit dem die CRL an einer vordefinierten Position veröffentlicht wird. Weitere Informationen über benutzerdefinierte Beendigungsmodule finden Sie im Kapitel Exit Modules im Security Platform SDK (englischsprachig) auf der Microsoft-Website.

Eine Online-CA auf einem Computer, der einer Active Directory-Domäne oder -Gesamtstruktur hinzugefügt wurde, veröffentlicht die CRL automatisch in Active Directory, sodass über LDAP darauf zugegriffen werden kann. Alternativ kann die CRL über einen HTTP-URL zugänglich gemacht werden, der auf eine Position auf einem Webserver verweist.

In Abhängigkeit von den Zertifikattypen, die von einer CA ausgestellt werden, ist auch die Reihenfolge der Sperrlisten-Verteilungspunkte von Bedeutung. Bei Authentifizierungszertifikaten ist es von Vorteil, wenn der CRL- oder vollqualifizierte LDAP-Sperrlisten-Verteilungspunkt der erste Eintrag in der Liste der Verteilungspunkte ist. Wird ein LDAP-Sperrlisten-Verteilungspunkt mit einem relativen Pfad angegeben, kontaktiert der Client den Domänencontroller, der entsprechend der Active Directory-Standortstruktur am nächsten liegt, um die CRL abzurufen. Mit vollqualifizierten LDAP-Sperrlisten-Verteilungspunkten erübrigt sich das Latenzproblem, das ggf. auftritt, bis die CRL in Active Directory repliziert worden ist. Bei nicht der Authentifizierung dienenden Zertifikaten möchten Sie ggf. LDAP verwenden, da LDAP in der Active Directory-Umgebung im Vergleich zu einem einzelnen HTTP-Server mehr Fehlertoleranz bietet.

Es besteht auch die Möglichkeit, sowohl den URL eines LDAP- als auch den URL eines HTTP-Sperrlisten-Verteilungspunktes festzulegen, um so zum einen Clients zu unterstützen, die für Active Directory aktiviert sind, und zum anderen Clients, die nicht unter Windows ausgeführt werden und Active Directory daher nicht unterstützen. Wenn Sie über eine Umgebung mit unterschiedlichen Clients verfügen oder sowohl interne als auch externe Clients bedienen müssen, empfiehlt sich als optimale Methode, den HTTP-Pfad zuerst in die Erweiterung des Sperrlisten-Verteilungspunktes zu setzen, um Netzwerkzeitüberschreitungen zu vermeiden. Jede Client, der bei der Zertifikatüberprüfung bei Bedarf eine CRL abruft, speichert eine Kopie der CRL als temporäre Datei in Internet Explorer, bis die CRL abgelaufen ist.

Tipp: Es empfiehlt sich als optimale Methode, eine CRL zu veröffentlichen, auf die extern über einen HTTP-Pfad zugegriffen werden kann, damit Benutzer und Anwendungen von außerhalb der Organisation eine Zertifikatüberprüfung durchführen können. Darüber hinaus empfiehlt es sich, Pfade und Namen zu verwenden, mit denen die interne Netzwerkinfrastruktur nicht für externe Einheiten offengelegt wird.

Die CRL enthält eine Liste der gesperrten Zertifikate, die von einer CA ausgestellt wurden. Die CRL enthält jedoch nicht die Gültigkeit von Zertifikaten, deren Inhaber eine untergeordnete CA ist, wie das CA-Zertifikat. Der Sperrstatus des Zertifikats einer untergeordneten CA wird von der dieser CA übergeordneten CA verwaltet, da die übergeordnete CA das Zertifikat der untergeordneten CA ausgestellt hat.

Da es für das Zertifikat einer Stammzertifizierungsstelle keine übergeordnete CA gibt, die die CRL verwalten könnte, ist es nicht notwendig, einen Sperrlisten-Verteilungspunkt für das Zertifikat der Stammzertifizierungsstelle selbst anzugeben. Wenn das Zertifikat einer Stammzertifizierungsstelle gesperrt werden soll, müssen stattdessen alle Zertifikate gesperrt werden, die von der Stammzertifizierungsstelle ausgestellt wurden.

Im Folgenden noch einige zusätzliche Planungshinweise:

Alle CAs unter Windows-Betriebssystemen entsprechen dem CRL V2-Format, das in RFC 2459 und RFC 3280 spezifiziert ist. Weitere Informationen über RFC 2459 und RFC 3280 finden Sie auf der IETF-Website (Internet Engineering Task Force) (nur in Englisch verfügbar).

Optimale Methoden in Verbindung mit auf LDAP basierenden CRLs

Die folgenden optimalen Methoden beziehen sich auf CRLs, die auf LDAP basieren:

Der erste Teil des Namens ist der Host- und Verteilungspunkt, d. h. der LDAP-Name des Servers, der als Host für den Sperrlisten-Verteilungspunkt fungiert; der zweite Teil des Namens ist der vollständige LDAP-Pfad der Verzeichnisposition, an der die CRL gespeichert ist. Die folgende Konfigurationszeichenfolge (oder der LDAP-Verweis):

ldap:///CN=,CN=

wird wie folgt interpretiert:

ldap://NächsterDomänencontrollerNachStandort/CN=,CN=

Bei Verwendung dieser Syntax wird Teil 1 des LDAP-Verteilungspunktes ausgelassen, jedoch automatisch eingefügt, wenn die CRL abgerufen werden muss. Mit der Syntax ldap:/// wird ein Client unter Windows 2000, Windows XP oder Windows Server 2003, der Mitglied einer Active Directory-Domäne ist, gezwungen, den nächstliegenden Domänencontroller zu suchen. Alternativ wird auch ein vollqualifizierter Domänenname (FQDN) oder ein exakter Serverpfad mit Angabe des Portwertes unterstützt.

Bei der Planung eines LDAP-Sperrlisten-Verteilungspunktes ist nicht nur der Pfad zur CRL wichtig; Sie müssen auch die richtigen Suchkriterien konfigurieren und diesen Suchpfad an den LDAP-Pfad anhängen.

Mit LDAP-Suchen können Suffixe zur Angabe von Attributen, Schachtelungstiefe und Objektklassen gesucht werden. Da im Verzeichnisdienst zahlreiche Objekte mit unterschiedlichen Datentypen im gleichen Pfad gespeichert sein können, ist es wichtig, die richtigen Daten abzufragen. Für ein Suchsuffix wird das folgende Format verwendet:

?attribute?depth?object_class

Wenn die Suchsuffixe attribute, depth und object_class fehlen, wählt der Client das richtige Objekt aus. Aufgrund der unterschiedlichen Clientimplementierungen funktioniert eine CRL-Überprüfung ohne diese erweiterten Informationen ggf. nicht.

Nachstehend das Beispiel eines relativen LDAP-Sperrlisten-Verteilungspunktes (auf einer Zeile):

ldap:///CN= CorporationRootCA,CN= Stamm_CA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC= contoso,DC= com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Im vorstehenden Beispiel sind CorporationRootCA, Stamm_CA, contoso und com Platzhalter, die durch die in der Organisation geltenden Parameter ersetzt werden müssen.

Nachstehend das Beispiel eines absoluten LDAP-Sperrlisten-Verteilungspunktes (auf einer Zeile):

ldap://cdp1.contoso.com/CN= CorporationRootCA,CN= Stamm_CA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC= contoso,DC= com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Im diesem Beispiel sind cdp1.contoso.com, CorporationRootCA, Stamm_CA, contoso und com Platzhalter, die durch die in der Organisation geltenden Parameter ersetzt werden müssen.

Optimale Methoden in Verbindung mit HTTP-URLs für Sperrlisten-Verteilungspunkte

Clients unter anderen Betriebssystemen als Windows sind ggf. nicht in der Lage CRLs über auf Active Directory basierenden LDAP-URLs abzurufen. Aus diesem Grund müssen Sie für LDAP-aktivierte Clients möglicherweise einen zusätzlichen HTTP-Pfad für den Sperrlisten-Verteilungspunkt angeben. Computer unter Windows unterstützen LDAP- und HTTP-URLs. Im Folgenden werden die optimalen Methoden für die Bereitstellung von HTTP-URLs für Sperrlisten-Verteilungspunkte erläutert:

Deltasperrlisten

In einer Produktionsumgebung steht die Anzahl der Zertifikate, die gesperrt werden, in direkter Beziehung zur Anzahl der ausgestellten Zertifikate. Die Liste der gesperrten Zertifikate kann je nach Anzahl der von einer CA ausgestellten Zertifikate unterschiedlich lang sein.

Gesperrte Zertifikate werden der CRL als Auflistung von Zertifikatseriennummern hinzugefügt. In RFC 2459 und RFC 3280 wird eine Methode definiert, die verwendet werden kann, um die Größe der Basis-CRL mithilfe von Delta-CRLs zu verringern. Delta-CRLs enthalten eine Liste der Zertifikate, die seit der letzten Veröffentlichung der Basis-CRL gesperrt wurden.

Basis-CRLs und Delta-CRLs werden von Clients unter Windows im Zwischenspeicher abgelegt. Zur Sicherstellung der Gültigkeit eines Zertifikats greift der Client auf die im lokalen Zwischenspeicher befindliche Basis- und Delta-CRL zurück, bis die Gültigkeitsdauer dieser CRLs abgelaufen ist. Nach Ablauf der Gültigkeit der Basis-CRL ruft der Client eine neue Basis-CRL von dem Verteilungspunkt ab, der im Zertifikat angegeben ist. Wenn die Basis-CRL noch gültig, die im Zwischenspeicher befindliche Delta-CRL allerdings abgelaufen ist, ruft der Client unter Windows nur die Delta-CRL ab. In der Regel ist die Delta-CRL wesentlich kleiner als die Basis-CRL, da hierin nur die Zertifikate aufgeführt sind, die seit der letzten Aktualisierung der Basis-CRL gesperrt wurden.

Optimale Methoden für Delta-CRLs:

Sie können die Delta-CRL täglich und die Basis-CRL wöchentlich veröffentlichen, damit Clients immer über die aktuellen Sperrungsinformationen verfügen und die Netzwerkbelastung (im Vergleich zur Netzwerkbelastung bei der Verteilung der Basis-CRL) dennoch gering gehalten wird. Wenn jedoch eine große Anzahl Zertifikate gesperrt wurde und wenn die Anzahl der zuletzt gesperrten Zertifikate die Zahl der gesperrten Zertifikate übersteigt, die sich bereits in der Basis-CRL befinden, übersteigt die Größe der Delta-CRL die der Basis-CRL. Beachten Sie jedoch, dass ein solches Szenario äußerst unwahrscheinlich ist und nicht als Normalfall betrachtet wird.

Sich häufig ändernde Delta-CRLs sollten nicht in Active Directory veröffentlicht werden, wenn die für die Replikation benötigte Zeit die Gültigkeitsdauer der Delta-CRL übersteigt.

Unterstützung des Online Certificate Status-Protokolls

Eine CA unter Windows ist nicht standardmäßig für die Unterstützung des OCS-Protokolls aktiviert. Sie können das OCS-Protokoll jedoch aktivieren, indem Sie in der CryptoAPI oder über den OCSP-Responder eines Drittanbieters einen Sperrungsanbieter installieren, der mit der Microsoft Zertifizierungsstelle kommuniziert. Für weitere Informationen über die CryptoAPI oder über Sperrungsanbieter suchen Sie auf der MSDN-Website nach dem Begriff CryptoAPI.

Optimale Methoden für die Veröffentlichung von CRLs

Das CRL-Veröffentlichungsintervall für CAs, die Zertifikate für CAs ausstellen, sollte länger sein als für CAs, die Zertifikate für Endeinheiten ausstellen, da die Sperrung eines CA-Zertifikats in der Regel nur äußerst selten erfolgt. Das empfohlene Erstellungsintervall für eine neue CRL diesen Typs liegt im Bereich von 90 bis 180 Tagen.

Eine CRL für eine Offline-CA sollte immer einige Tage vor Ablauf der alten CRL erfolgen, um unerwarteten Problemen vorzubeugen. Das Veröffentlichungsintervall für ausstellende CAs sollte dem Typ des ausgestellten Zertifikats entsprechend festgelegt werden. Für Authentifizierungszertifikate ist ggf. ein längeres Veröffentlichungsintervall als für andere Zertifikattypen sinnvoll.

Bei der CRL-Veröffentlichung für Offline-CAs sollten zudem die folgenden Punkte berücksichtigt werden:

AIA-Erweiterungen

Mit der AIA-Erweiterung ist der Zertifikatnutzer in der Lage, eine aktuelle Kopie des aktuellen Zertifikats der CA abzurufen. CA-Zertifikate werden benötigt, wenn eine Zertifikatkette aufgebaut wird. Der Aufbau der Kette erfolgt als Teil des Zertifikatüberprüfungsprozesses.

Gehen Sie bei der Konfiguration von AIA-Erweiterungen mit der gleichen Sorgfalt und Detailgenauigkeit wie bei der Konfiguration von Erweiterungen für Sperrlisten-Verteilungspunkte vor. Das folgende Beispiel enthält weitere Informationen über die AIA-Erweiterung in einem Zertifikat.

Abbildung 4. AIA-Erweiterungen
Bild maximieren

Bei CA-Zertifikaten handelt es sich um mehrwertige, Base64-codierte Attribute in Active Directory, in denen mehr als ein CA-Zertifikat gespeichert werden kann. Für jede CA wird ein mehrwertiges AIA-Attribut verwendet, da eine CA nach der CA-Erneuerung über mehr als ein gültiges Zertifikat verfügen kann.

Beachten Sie, dass die Zahl der Werte, die gespeichert werden können, auch bei mehrwertigen Attributen begrenzt ist. Daher können mit Sicherheit nicht mehr als 1.000 CA-Zertifikate in einem AIA-Objekt gespeichert werden.

Im Vergleich zu einem LDAP-AIA-URL, der auf ein mehrwertiges Objekt verweist und die Zertifikate im gleichen Objekt mithilfe des Suchsuffixes unterschieden, verweist ein HTTP-AIA-URL nur auf eine einzelne Datei. Aus diesem Grund müssen alle HTTP-URLs das Zertifikatsuffix (*.CER, *.CRT usw.) als Suffix für den Dateinamen enthalten, um die verschiedenen Zertifikate unterscheiden zu können, die im gleichen Verzeichnis auf dem HTTP-Server gespeichert sind.

In der folgenden Tabelle wird die Struktur erläutert, mit der Zertifikate gespeichert werden. Beachten Sie, dass ein HTTP-Pfad eindeutig sein muss und dass sich unter jedem expliziten URL-Pfad immer nur ein CRL-Objekt (oder eine Datei) befinden darf. Ein LDAP-Pfad verweist hingegen auf ein einzelnes Objekt in Active Directory, das ein mehrwertiges Attribut unterstützt.

Tabelle 12. Beispiel für die Speicherstruktur von Zertifikaten

Gültigkeitsdauer und Schlüssellänge von Zertifikaten

Die Gültigkeitsdauer von Zertifikaten ist von den Anforderungen einer Organisation abhängig. Die folgende Tabelle enthält einige Empfehlungen für die Gültigkeitsdauer von Zertifikaten unterschiedlicher CA-Typen.

Tabelle 13. Empfehlungen im Hinblick auf die Gültigkeitsdauer

Hinweis: Alle vorstehend genannten Werte sind lediglich als Vorschläge zu sehen; die reale Vorgehensweise kann von juristischen, behördlichen oder vertraglichen Regeln bestimmt werden, die spezifisch für eine Organisation gelten. Werden während der Erneuerung und der Neuverschlüsselung von CAs Änderungen an Richtlinien und Erweiterungen vorgenommen, werden im Nachgang ggf. auch Änderungen an der Zertifizierung der Zertifikatverwendungserklärung, an den Überwachungsmethoden usw. fällig.

Zum Seitenanfang

Beispielszenario für die Firma Contoso

Da der vorstehende Abschnitt mit all den Planungsüberlegungen und optimalen Methoden doch sehr theoretisch ist, soll hier nun ein reales Beispiel einer PKI-Topologie vorgestellt werden. In diesem Beispiel werden die optimalen Methoden näher erläutert, die an früherer Stelle in diesem Dokument aufgeführt sind. Darüber hinaus werden auch die meisten der Optionen einer komplexen PKI dargelegt. Wenn Sie bestimmte Komponenten (wie das Hardwaresicherheitsmodul oder die Hierarchieebene mit den Zwischenzertifizierungsstellen) weglassen, können Sie diese Topologie auch an die Umgebung kleinerer Organisationen anpassen.

Die fiktive Firma trägt den Namen Contoso. Contoso ist ein international agierendes Unternehmen. Es wurde bereits Active Directory implementiert, und nun ist man mit der Einführung einer PKI unter Windows Server 2003 befasst. Die Projektplanungsphase ist bereits abgeschlossen. Neben anderen vorbereitenden Aufgaben sind für die Konfiguration der PKI auch die in Anhang B aufgeführten Parameter erforderlich.

Gehen Sie gemäß den folgenden Installationsanweisungen vor, um eine PKI ähnlich der Contoso-PKI einzurichten.

Entscheidung im Hinblick auf die Plattform

Bei Contoso hat man sich für die Implementierung einer PKI-Hierarchie unter Windows Server 2003 entschieden. Hierbei schätzt man vor allem die Einfachheit der Implementierung, die Vorteile der verstärkten Sicherheit, die sicherheitsintegrierten Anwendungen sowie die in Active Directory integrierte Verwaltungsstruktur, die über die bereits vorhandene Active Directory-Infrastruktur gepflegt werden kann.

Da man bei Contoso alle Vorteile der verbesserten PKI unter Produkten der Windows Server 2003-Produktfamilie nutzen möchte, wurde Active Directory für die Ausführung in einer Windows Server 2003-Gesamtstruktur und im Funktionsmodus Windows Server 2003-Domäne konfiguriert. Weitere Informationen über das Heraufstufen der Domänenfunktionsebene auf einem Computer unter einem Produkt der Windows Server 2003-Produktfamilie finden Sie im Artikel HOW TO: Raise the Domain Functional Level in the Windows .NET Server Family (englischsprachig) in der Microsoft Knowledge Base.

Bei Contoso wird mit unterschiedlichen Clients gearbeitet, auf denen entweder ein Produkt aus der Windows 2000-Produktfamilie oder Windows XP Professional ausgeführt wird. Darüber hinaus kommt eine Reihe integrierter Anwendungen zum Einsatz, die die PKI unter Windows Server 2003 nutzen können, wie S/MIME (Secure/Multipurpose Internet Mail Extensions), das verschlüsselnde Dateisystem (Encrypting File System - EFS), L2TP- oder IPSec-VPN-Verbindungen, drahtloser Zugriff gemäß 802.1x und für SSL aktivierte Webserver. Für die Benutzeranmeldung werden Smartcards verwendet.

Entwurf der PKI

Bei Contoso ist man zu dem Schluss gekommen, dass eine dreischichtige PKI-Topologie für die Organisation am besten geeignet ist. Aber auch wenn man sich für eine zweischichtige PKI-Topologie entschieden hätte, würden die in diesem Dokument erläuterten Implementierungsrichtlinien gelten.

Die PKI von Contoso enthält unterschiedliche Zertifikatserver. Jede CA wird mit Zertifikatdiensten implementiert, wie sie mit Windows Server 2003, Enterprise Edition, installiert werden. Die folgende Abbildung zeigt die Zertifikatdienstearchitektur der Firma Contoso.

Abbildung 5. CA-Hierarchie der Firma Contoso
Bild maximieren

Stammzertifizierungsstelle

Die eigenständige Stammzertifizierungsstelle von Contoso ist niemals mit dem Netzwerk verbunden, bleibt offline und wird physikalisch gesichert. Die Stammzertifizierungsstelle stellt Zertifikate für Zwischenzertifizierungsstellen in der Hierarchie aus und sperrt diese. Zur Erhöhung des Sicherheitsniveaus des privaten Schlüssels der Stammzertifizierungsstelle wird die Hardwarekonfiguration der Stammzertifizierungsstelle um ein Hardwaresicherheitsmodul erweitert. Das CA-Zertifikat und die CRL werden manuell veröffentlicht und über einen HTTP- und einen LDAP-Verteilungspunkt verfügbar gemacht.

Zwischenzertifizierungsstellen

Die Zwischenzertifizierungsstellen werden physikalisch gesichert und offline betrieben. Bei Contoso hat man sich für den Betrieb von zwei Zwischenzertifizierungsstellen entschieden. Durch die Trennung der Zwischenzertifizierungsstellen ist die Organisation in der Lage, mit verschiedenen Sperrlisten-Verteilungspunkten und -Veröffentlichungsintervallen zu arbeiten. Da auch die Zwischenzertifizierungsstellen als potenziell gefährdete Komponenten in der PKI der Organisation betrachtet werden, sind auch sie mit Hardwaresicherheitsmodulen ausgestattet.

Ausstellende CAs

Die ausstellenden Unternehmenszertifizierungsstellen sind für die Registrierung von Zertifikaten für Endeinheiten zuständig. Diese CAs sind auf unterschiedliche geografischen Standorte verteilt, um eine lokale Verfügbarkeit zu ermöglichen. Allerdings hat die physikalische Sicherheit Vorrang vor der Nähe der Server. Diese CA-Server werden online betrieben und stehen jederzeit für Dienstanforderungen zur Verfügung. Die Verfügbarkeit kann zukünftig noch erhöht werden, indem weitere ausstellende CAs implementiert werden.

Die Umgebung von Contoso - Zusammenfassung

In der folgenden Liste wird die Umgebung von Contoso zusammengefasst:

Eigenständige Offline-Stammzertifizierungsstelle

Im folgenden Abschnitt werden die Schritte für die Installation einer Offline-Stammzertifizierungsstelle auf einem Computer unter Windows Server 2003, Standard Edition, erläutert. Das Installationsverfahren für eine CA unter Windows 2000 ist mit dem auf einem Computer unter Windows Server 2003, Standard Edition, vergleichbar, daher gelten die hier beschriebenen Schritte auch für Computer unter Windows 2000.

Hinweis: Die eigenständige Offline-Stammzertifizierungsstelle wird in diesem Dokument auch als CorporateRootCA bezeichnet.

Installationsvoraussetzungen

Auf dem Server, auf dem Windows Server 2003, Standard Edition, ausgeführt werden soll, werden das Basisbetriebssystem und die neuesten Aktualisierungen installiert. Vergewissern Sie sich, dass Sie vor Beginn der Installation der Zertifikatdienste über die folgenden Informationen/Materialien verfügen:

Installieren der Offline-Stammzertifizierungsstelle

Gehen Sie wie in diesem Abschnitt beschrieben vor, um die Stammzertifizierungsstelle einzurichten. Vergewissern Sie sich zu Beginn, dass die folgenden Konzepte von der Organisation geprüft und genehmigt wurden:

Arbeitsgruppenmitgliedschaft

Bei CorporateRootCA muss es sich um ein Arbeitsgruppenmitglied handeln, da sie nicht an das Netzwerk angeschlossen und nicht mit einem Domänencontroller verbunden ist. Dennoch muss der Servername in der Organisation eindeutig sein, da der Servername Teil der Informationen ist, die in Active Directory veröffentlicht werden.

Melden Sie sich an einem lokalen Computer an, und vergewissern Sie sich, dass die Benennungsinformationen richtig sind, indem Sie an der Befehlseingabeaufforderung den Befehl net config workstation eingeben. (Beachten Sie, dass die Werte in Kursivschrift entsprechend der jeweiligen Konfiguration in Ihrer Organisation unterschiedlich sein können.) Der folgende Abschnitt enthält ein Beispiel zur Verwendung des Befehls net config workstation zu diesem Zweck.

D:\>net config workstation Computername                        \\CONCORP-CA-00 
Vollständiger Computername                   concorp-ca-00 
Benutzername                             Administrator  
Arbeitsstation aktiv an 
         NetbiosSmb (000000000000) 
         NetBT_Tcpip_{7CD8C0C6-02A5-4EB4-8081-5D1977FD0AA5} (0008C75BDEC0) 
Softwareversion                     Microsoft Windows Server 2003 
Arbeitsstationsdomäne                    WORKGROUP  
Anmeldedomäne                          CONCORP-CA-00  COM 
COM offen: Zeitüberschreitung (s)               0 
COM gesendete Anzahl (Bytes)                16 
COM senden: Zeitüberschreitung(ms)              250 
Der Befehl wurde erfolgreich ausgeführt.

Vergewissern Sie sich, dass der Name der Anmeldedomäne dem Namen Ihres Servers entspricht.

Weitere Informationen finden Sie in den folgenden Artikeln auf diversen Microsoft-Websites:

Installieren eines Hardwaresicherheitsmoduls für eine Offline-Stammzertifizierungsstelle

Einige Organisationen ziehen es ggf. vor, den privaten Stammschüssel mit zusätzlicher Hardware zu schützen. Bevor Sie die Zertifikatdienste installieren und konfigurieren, sollten Sie überprüfen, dass das HSM ordnungsgemäß und entsprechend den Installationsanweisungen des Hardwareherstellers konfiguriert ist. Informationen über die Installation eines HSMs auf Computer, auf denen entweder Windows 2000 oder Windows Server 2003 ausgeführt wird, finden Sie auf den folgenden Websites:

Vorbereiten der Datei "CAPolicy.inf" für die Stammzertifizierungsstelle

Ein ausgestelltes Zertifikat erbt in der Regel die Eigenschaften (z. B. Zertifikatgültigkeitsdauer, Verteilungspunkt der CRL und weitere Parameter) der Zertifikatvorlage, die von der ausstellenden CA bereitgestellt wird. Da die Stammzertifizierungsstelle selbst ein Zertifikat benötigt, muss sie dieses Zertifikat selbst signieren, da es keine übergeordnete CA gibt, die dieses Zertifikat ausstellen könnte.

Bevor das Zertifikat der CA generiert wird, ist eine benutzerdefinierte Konfiguration der CA erforderlich, für die das CA-Zertifikat gelten soll. Die Datei CAPolicy.inf umfasst sämtliche Konfigurationsinformationen, die erforderlich sind, um ein selbstsigniertes CA-Zertifikat entsprechend den Anforderungen der Organisation zu generieren.

Warnung: Die Konfiguration der Datei CAPolicy.inf ist ein außerordentlich wichtiger Schritt, der abgeschlossen sein muss, bevor Sie eine Stammzertifizierungsstelle unter Windows Server 2003 einrichten. Wird die Datei CAPolicy.inf nicht für das Setup der Offline-Stammzertifizierungsstelle verwendet, werden die CRL- und AIA-Verteilungspunkte, die zum Bestandteil von ausgestellten Zertifikaten werden, so festgelegt, dass sie auf Verteilungspunkte auf dem lokalen Computer verweisen. Da auf eine Offline-CA niemals aus dem Netzwerk zugegriffen werden kann, können die Clients in diesem Fall die CRL- oder AIA-Verteilungspunkte nicht auflösen. Zur Vermeidung dieses Problems müssen Sie die beiden Parameter CRLDistributionPoint und AuthorityInformationAccess explizit in die Datei CAPolicy.inf aufnehmen. Wie im Abschnitt Optimale Methoden in Verbindung mit CRLs bereits erwähnt, müssen sowohl der CRL- als auch der AIA-Sperrlisten-Verteilungspunkt einer Stammzertifizierungsstelle als leer definiert werden.

So können Sie sicherstellen, dass die Datei CAPolicy.inf ordnungsgemäß verarbeitet wird:

Die Syntax entspricht der Spezifikation, die im Abschnitt Syntax der Datei "CAPolicy.inf" im Anhang dieses Dokuments erläutert ist.

Hinweis: Nachdem Sie die Datei CAPolicy.inf für eine CA verwendet haben, dürfen Sie diese nicht vom Computer entfernen, da Konfigurationsparameter wie Länge des Erneuerungsschlüssels über die gesamte Lebensdauer der CA die gleichen bleiben müssen.

Darüber hinaus wird auch im Verlauf der Installation keine Warnung ausgegeben, wenn das Format der Datei CAPolicy.inf nicht den Vorgaben entspricht, da es keinen Syntax- oder Fehlerüberprüfungsmechanismus gibt. Informationen zur Setupprotokollierung und zum Debugging finden Sie in der Datei Systemroot \ Certocm.log.

So konfigurieren Sie die Datei CAPolicy.inf:

Installieren der Softwarekomponenten der Offline-Stammzertifizierungsstelle

Wichtig: Führen Sie sämtliche Umbenennungsvorgänge durch, bevor die CA-Dienste Bestandteil der Konfiguration werden. Sie können den Namen des NetBIOS-Computers oder die Mitgliedschaft des Computers in einer Domäne oder Arbeitsgruppe nach der Installation der Zertifikatdienste nicht mehr ändern, da der Name dann Teil der Konfigurationsinformationen der Zertifizierungsstelle ist.

Gehen Sie zum Installieren der Softwarekomponenten der Offline-Stammzertifizierungsstelle wie folgt vor:

1.	Melden Sie sich an dem Computer, auf dem CorporateRootCA eingerichtet werden soll, als Administrator an. Beachten Sie, dass dieses Konto während des CA-Installationsverfahrens über die Berechtigungen eines CA-Administrators verfügt. Sie können die Rolle des CA-Administrators nach Abschluss der Setup- und Konfigurationsverfahren an andere Benutzerkonten delegieren. Weitere Informationen zu CA-Funktionen und -Berechtigungen finden Sie in der Windows Server 2003-Hilfe.
2.	Öffnen Sie mit einem der folgenden Verfahren das Dialogfeld Windows-Komponenten hinzufügen/entfernen: 1. a. So verwenden Sie die Eingabeaufforderung: i. Klicken Sie auf Start, dann auf Ausführen, geben Sie cmd ein, und klicken Sie auf OK. ii. Geben Sie an der Eingabeaufforderung sysocmgr /i:sysoc.inf ein, und drücken Sie die EINGABETASTE. 2. b. So verwenden Sie die Systemsteuerung: i. Klicken Sie auf Start, zeigen Sie auf Einstellungen, und klicken Sie dann auf Systemsteuerung. ii. Klicken Sie auf Software. iii. Klicken Sie im Dialogfeld Software auf Windows-Komponenten hinzufügen/entfernen. Hinweis: Prüfen Sie zum Ausführen der Zertifikatdienste das Vorhandensein der folgenden Softwarekomponenten: • Zertifikatdienste • Internet Explorer • (Optional) Webregistrierungssupport für Zertifikatdienste • (Optional) Internetinformationsdienste für Webregistrierungssupport Sie sollten auf einer Windows Server-Zertifizierungsstelle keine weiteren Windows-Komponenten installieren. Bei der Installation weiterer Komponenten kann die Zuverlässigkeit oder Sicherheit einer Stammzertifizierungsstelle gefährdet werden, wenn die Organisation eine sichere Konfiguration benötigt. Eine Offline-CA unter Windows 2000 setzt zur Unterstützung der Offline-CA-Registrierung IIS voraus. Im Gegensatz zu Windows 2000 Server kann eine Zertifizierungsstelle unter Windows Server 2003 Offline-Zertifikatanforderungen mithilfe des MMC-Snap-Ins für Zertifizierungsstellen verarbeiten.
3.	Aktivieren Sie im Assistenten für Windows-Komponenten das Kontrollkästchen Zertifikatdienste, und klicken Sie dann auf Weiter.
4.	Klicken Sie unter Zertifizierungsstellentyp auf Eigenständige Stammzertifizierungsstelle, aktivieren Sie das Kontrollkästchen Schlüsselpaar und ein Zertifizierungsstellenzertifikat mit diesen Einstellungen erstellen, und klicken Sie dann auf Weiter. Die Optionen Stammzertifizierungsstelle des Unternehmens und Untergeordnete Zertifizierungsstelle des Unternehmens stehen erwartungsgemäß nicht zur Verfügung, weil der Computer kein Mitglied einer Active Directory-Domäne ist.
5.	Führen Sie einen der folgenden Schritte durch: • Wenn ein HSM installiert wurde, wählen Sie unter Kryptografiedienstanbieter den Kryptografiedienstanbieter (Cryptographic Service Provider - CSP) aus, der bei der HSM-Installation installiert wurde. • Wenn kein HSM installiert wurde, klicken Sie in Kryptografiedienstanbieter auf Microsoft Strong Cryptographic Provider.
6.	Klicken Sie in Hashalgorithmus auf den standardmäßigen Hashalgorithmus SHA-1. SHA-1 ist der gebräuchlichste Hashalgorithmus mit der größten Interoperabilität, der von Anwendungen und Betriebssystemen verwendet wird. Weitere Informationen zur Unterstützung von Kryptografiedienstanbietern auf Computern unter Windows 2000 finden Sie unter Microsoft Enhanced CSP Is Not Supported for Certificate Services Installations (englischsprachig) in der Microsoft Knowledge Base.
7.	Klicken Sie unter Schlüssellänge auf 4096. Wenn Sie eine andere Schlüssellänge auswählen, vergewissern Sie sich, dass diese Schlüssellänge mit den in der Organisation eingesetzten Anwendungen und anderen PKI-Komponenten kompatibel ist. Die in das Feld eingegebene Schlüssellänge wird nicht überprüft. Wird ein HSM- oder ein Smartcard-Kryptografiedienstanbieter verwendet, muss dieser mit dem Desktop zusammenarbeiten.
8.	Vergewissern Sie sich, dass die beiden Kontrollkästchen Kryptografiedienstanbieter Zugriff auf Desktop gestatten und Vorhandenen Schlüssel verwenden deaktiviert sind, und klicken Sie dann auf Weiter.
9.	Geben Sie auf der Registerkarte Informationen über die Zertifizierungsstelle im Feld Allgemeiner Name dieser Zertifizierungsstelle einen aussagekräftigen Namen für die Zertifizierungsstelle ein. Verwenden Sie für dieses Beispiel CorporateRootCA. Wie in der Zertifikatverwendungserklärung angegeben, müssen Sie einen allgemeinen Namen (Common Name - CN) für diese Zertifizierungsstelle eingeben. Die Länge des CN darf 64 Zeichen nicht überschreiten. Sie sollten jedoch einen Namen mit maximal 51 Zeichen verwenden, um eine Verletzung der Codierungslängenregel zu vermeiden.
10.	(Optional) Geben Sie in Suffix des definierten Namens den Eintrag DC=concorp,DC=contoso,DC=com ein. Vergewissern Sie sich bei Eingabe eines Namens, dass dieser keine Tippfehler enthält, damit im Kontext des Active Directory-Domänennamens keine Probleme auftreten. Im Contoso-Szenario lautet der definierte Name DC=concorp,DC=contoso,DC=com. Wenn Sie eine CA auf einem Computer installieren, der ein Domänenmitglied mit Organisationsadministratorrechten ist, wird das Suffix des definierten Namens automatisch konfiguriert. Sie können das Suffix des definierten Namens auch zu einem späteren Zeitpunkt unter Verwendung des Befehls Certutil.exe festlegen.
11.	Wählen Sie unter Gültigkeitsdauer den Eintrag 10 Jahre aus. Geben Sie die Gültigkeitsdauer wie in der Zertifikatverwendungserklärung der Organisation definiert ein. In diesem Beispiel wird für CorporateRootCA eine Gültigkeitsdauer von 10 Jahren festgelegt.
12.	Wenn auf diesem Computer bereits eine Zertifizierungsstelle deinstalliert wurde, wird eine Warnmeldung mit der Bestätigung angezeigt, dass der private Schlüssel der vorherigen CA-Installation überschrieben werden soll. Sie sollten sicherstellen, dass der private Schlüssel nie mehr benötigt wird. Wenn Sie eine Sicherungskopie des Systems erstellen, steigt die Wahrscheinlichkeit, dass keine Daten verloren gehen. (Anstelle einer Sicherheitskopie des gesamten Systems können Sie auch eine Sicherheitskopie des privaten Schlüssels erstellen. Geben Sie hierzu an einer Eingabeaufforderung den Befehl certutil -backupkey -? ein.) Klicken Sie auf Nein, wenn Sie sich nicht sicher sind, ob der private Schlüssel überschrieben werden soll, um so die Installation abzubrechen. Wenn Sie auf Ja klicken, wird ein neuer Schlüssel generiert, der den vorhandenen Schlüssel ersetzt. Beachten Sie, dass die Festlegung des Suffixes des definierten Namens bei CAs unter Windows 2000 nicht als Teil des Installations-Assistenten erfolgen kann. Das Schlüsselpaar aus öffentlichem und privatem Schlüssel wird nun vom Kryptografiedienstanbieter generiert. Bei Verwendung des standardmäßigen Kryptografiedienstanbieters werden die Schlüssel in den Schlüsselspeicher des lokalen Computers geschrieben. Wird kein HSM verwendet, wird der Schüssel von der CryptoAPI generiert und im Profil des Systemkontos auf dem lokalen Computer gespeichert. Die für die Generierung des Schlüssels erforderliche Zeitdauer ist sowohl von der Größe des zu generierenden Schlüssels als auch von der CPU-Leistung des lokalen Computers abhängig. Wenn ein HSM installiert ist und ausgewählt wurde, wird der Schlüssel im HSM generiert und entsprechend der HSM-spezifischen Architektur gespeichert. Da bei einem eigenständigen CA-Server, der Mitglied einer Arbeitsgruppe ist, keine Zertifikatvorlagen zur Verfügung stehen, muss das CA-Zertifikat aus den Konfigurationsinformationen in der Registrierung erstellt werden. Die folgenden Standardwerte der Schlüsselverwendungserweiterung werden dem CA-Zertifikat hinzugefügt: • Digitale Signatur • Zertifikatsignatur • Zertifikatsignatur der Offline-Zertifikatsperrliste • Zertifikatsignatur der Zertifikatsperrliste Wenn eine Stammzertifizierungsstelle jedoch auf einem Computer installiert ist, auf dem ein Produkt aus der Windows 2000- oder der Windows Server 2003-Produktfamilie ausgeführt wird und dieses Computer ein Domänenmitglied ist, erbt die CA die Einstellungen der Erweiterung für erweiterte Schlüsselverwendung von der CA-Vorlage in Active Directory, und zwar auch dann, wenn die CA als eigenständige CA installiert wurde. Wenn Active Directory nicht verfügbar ist, werden die Einstellungen für die erweiterte Schlüsselverwendung ebenfalls der Konfiguration entnommen, die in der Registrierung zur Verfügung steht.
13.	Geben Sie unter Zertifikatdatenbank und Zertifikatdatenbankprotokoll die Pfade zur Zertifikatdatenbank und zu den Protokolldateien der Zertifikatdatenbank ein. Zertifikatdatenbank und Zertifikatdatenbankprotokoll müssen auf einer lokalen NTFS-Festplatte gespeichert werden. Bei einer eigenständigen CA, bei der davon ausgegangen wird, dass nur selten CA-Zertifikate ausgestellt werden, können sowohl die Zertifikatdatenbank als auch das Zertifikatdatenbankprotokoll auf der Festplatte des lokalen Computers verbleiben. Zur Sicherstellung der Zuverlässigkeit und Verfügbarkeit der CA sollten zeitgesteuerte Datensicherungen des Computers geplant werden. Datensicherungen können auch dann erstellt werden, wenn der CA-Dienst nicht ausgeführt wird. Weitere Informationen über die Datensicherung und -wiederherstellung einer CA finden Sie unter Datensicherung und -wiederherstellung für eine Zertifizierungsstelle in diesem Dokument.
14.	(Optional) Aktivieren Sie das Kontrollkästchen Vorhandene Zertifikatdatenbank nicht löschen, um eine Zertifizierungsstelle am gleichen Speicherort zu installieren. Bei Auswahl dieser Option verwendet die neue CA die vorhandene Datenbank und behält die Zertifikate in der Datenbank bei. Wird diese Option nicht aktiviert, wird die vorhandene Datenbank gelöscht. Sie sollten diese Option nur dann verwenden, wenn Sie versuchen, eine CA aus eine Datensicherung wiederherzustellen oder wenn die CA migriert werden soll. Sie können sowohl die Datenbank als auch die Protokolldateien an eine andere Speicherposition verschieben. Weitere Informationen finden Sie unter HOW TO: Move the Certificate Server Database and Log Files (englischsprachig) in der Microsoft Knowledge Base.
15.	Aktivieren Sie das Kontrollkästchen Konfigurationsinformationen in einem freigegebenen Ordner speichern, und geben Sie unter Freigegebener Ordner einen lokalen Pfadnamen als Namen für den freigegebenen Ordner wie C:\CAConfig ein. Klicken Sie anschließend auf Weiter. Im Verlauf des CA-Setupverfahrens kann nicht ermittelt werden, ob der Computer als Online- oder Offline-CA betrieben werden soll. Für eine Offline-CA ist der freigegebene Ordner zwar nicht erforderlich, muss aber dennoch angegeben werden. Wenn die CA mit dem Netzwerk verbunden ist, können Clients über den freigegebenen Ordner auf das CA-Zertifikat zugreifen. Je nach Name des freigegebenen Ordners wird auf dem CA-Server eine neue Freigabe erstellt. Bei dem Pfad zu dem freigegebenen Ordner kann es sich entweder um einen UNC-Pfad (Universal Naming Convention) wie dem Standardpfad \\Localhost\CAConfig oder um einen lokalen Pfad wie C:\CAConfig handeln. Wenn der Server nicht mit Netzwerkkarten ausgerüstet ist oder wenn alle Netzwerkschnittstellen deaktiviert sind, müssen Sie einen lokalen Pfad angeben. Einige Informationen, die im Konfigurationsverzeichnis der CA gespeichert sind, müssen in einem späteren Schritt in Active Directory veröffentlicht werden. Weitere Informationen hierüber finden Sie unter Importieren der Zertifikate und Sperrlisten der übergeordneten Zertifizierungsstelle in Active Directory an späterer Stelle in diesem Dokument. Wenn die Konfiguration der Zertifikatdienste mit dem Assistenten für Windows-Komponenten abgeschlossen ist, werden Sie ggf. aufgefordert, das Installationsmedium des Servers einzulegen, damit die Installation fertig gestellt werden kann. Da Sie IIS auf diesem Computer nicht installieren müssen, erhalten Sie möglicherweise eine Warnmeldung, die besagt, dass der Webregistrierungssupport für die Zertifikatdienste nicht verfügbar ist. Wenn diese Meldung angezeigt wird, klicken Sie auf OK, um die Installation abzuschließen. Abbildung 6. IIS-Installationswarnung Bild maximieren

Überprüfen der Konfiguration der Stammzertifizierungsstelle

Mit dem nächsten Verfahren können Sie sicherstellen, dass die Stammzertifizierungsstelle ordnungsgemäß konfiguriert ist und in die Produktionsumgebung übernommen werden kann.

Überprüfen des Zertifikats der Stammzertifizierungsstelle

Da das Zertifikat der Stammzertifizierungsstelle für eine zuverlässige Überprüfung aller in der PKI ausgestellten Zertifikate unerlässlich ist, müssen Sie unbedingt sicherstellen, dass dieses Zertifikat alle notwendigen Informationen enthält, bevor Sie mit der Installation der CA-Hierarchie fortfahren.

Signaturealgorithmus:     
Algorithmus Objektkennung: 1.2.840.113549.1.1.5  sha1RSA  
Aussteller:  CN=CorporateRootCA  
Nicht vor: 6/5/2002 7:47 PM 
Nicht nach: 6/5/2012 7:54 PM 
Antragsteller:  CN=CorporateRootCA

Überprüfen der Konfigurationsinformationen von "CorporateRootCA"

Mit den in diesem Abschnitt aufgeführten Schritten können Sie die CA-Konfiguration überprüfen:

CA Type: 3 -- Eigenständige Stammzertifizierungsstelle     
ENUM_STANDALONE_ROOTCA -- 3

Konfigurationsverzeichnis   REG_SZ =  \\concorp-ca-00\CertConfig
    Datenbankverzeichnis              REG_SZ =  C:\WINDOWS\system32\CertLog
    Datenbankprotokollverzeichnis           REG_SZ =  C:\WINDOWS\system32\CertLog
    Datenbanksystemverzeichnis        REG_SZ =  C:\WINDOWS\system32\CertLog
    Datenbank Temp-Verzeichnis          REG_SZ =  C:\WINDOWS\system32\CertLog

Konfiguration der Offline-Stammzertifizierungsstelle

Nachdem die eigenständige Offline-Zertifizierungsstelle installiert wurde, müssen deren Eigenschaften für die Zertifikate konfiguriert werden, die in Folge von der CA ausgestellt werden. Diese Erweiterungen sind notwendig, um eine ordnungsgemäße Sperrung sowie die Zertifkatkettenerstellung sicherzustellen.

Sie können alle in diesem Abschnitt beschriebenen Schritte mithilfe eines einzigen Stapelverarbeitungsskripts durchführen. Weitere Informationen finden Sie unter Beispielskript zum Konfigurieren von "CorporateRootCA" in diesem Dokument.

Zuordnen des Namespace von Active Directory zur Registrierungskonfiguration einer Offline-CA

Achtung: Durch eine fehlerhafte Bearbeitung der Registrierung kann ernsthafter Schaden am Computer verursacht werden. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie eine Sicherungskopie aller wichtigen Daten auf dem Computer erstellen.

Da die Offline-Stammzertifizierungsstelle nicht mit der Domäne verbunden ist und die CRL nicht automatisch in Active Directory veröffentlicht, müssen Sie den entsprechenden Schlüssel in der Registrierung setzen. Geben Sie zu diesem Zweck an der Eingabeaufforderung den folgenden Befehl ein. Stoppen Sie dann den CA-Dienst, und starten Sie ihn erneut:

certutil.exe -setreg ca\DSConfigDN CN=Configuration,DC=concorp,DC=contoso,DC=com

Hierbei steht DC=concorp,DC=contoso,DC=com für den Namespace der Stammdomäne der Gesamtstruktur. Diese Einstellung ist in erster Linie für CRLs und CA-Zertifikate (AIA) erforderlich, die in Active Directory veröffentlicht werden sollen.

Mit diesem Registrierungswert wird das Platzhaltertoken %6 festgelegt, das für das CRL-Pfadattribut sowie die CRL- und AIA-Verteilungspunkte erforderlich ist, die unter Konfigurieren der CorporateRootCA-Verteilungspunkte für CRL und AIA erläutert werden. Weitere Informationen über das Platzhaltertoken %6 finden Sie unter Platzhaltertoken für Sperrlisten-Verteilungspunkt in diesem Dokument.

Wichtig: Nachdem Sie diesen Befehl zum Ändern des Registrierungsschlüssels verwendet haben, muss eine neue CRL und müssen alle neuen CA-Zertifikate, die ausgestellt werden, erneut veröffentlicht werden. Nur neue Zertifikate, die nach der Verwendung des vorstehenden Befehls ausgestellt werden, enthalten diese Informationen. Es ist zudem wichtig anzumerken, dass Sie auch alle Zertifikate für untergeordnete CAs erneut ausstellen und veröffentlichen müssen, sofern solche vor der Änderung des Registrierungsschlüssels ausgestellt wurden.

Konfigurieren von "CorporateRootCA"-Verteilungspunkten für CRL und AIA

Die CRL- und AIA-Verteilungspunkte müssen festgelegt werden, bevor von der neuen CA irgendwelche Zertifikate ausgestellt werden.

Mit diesem Konfigurationsschritt wird sichergestellt, dass die richtigen Informationen in jedes ausgestellte Zertifikat integriert werden, damit die Signatur und der Sperrstatus des Zertifikats überprüft werden kann. Weitere Informationen über den Zertifikatstatus und die Erstellung von Zertifikatsketten sowie über die Verwendung von AIA- und Sperrlisten-Verteilungspunkterweiterungen, die von der CryptoAPI verwenden werden, finden Sie unter Troubleshooting Certificate Status and Revocation (englischsprachig) auf der Microsoft TechNet-Website.

Die Konfiguration der AIA-Erweiterung und der Sperrlisten-Verteilungspunkterweiterung ist für alle Zertifizierungsstellentypen (Online oder Offline, Stamm- oder untergeordnete Zertifizierungsstelle, Unternehmens- oder eigenständige Zertifizierungsstelle) von ausschlaggebender Bedeutung. Erfolgt deren Konfiguration nicht ordnungsgemäß oder sind ungültige Erweiterungen enthalten, kann es zu unerwarteten Problemen kommen. Beispielsweise können Anmeldeversuche per Smartcard fehlschlagen, es können ungültige digitale E-Mail-Signaturen auftreten, oder es kann Websites geben, die als nicht vertrauenswürdig gelten.

Konfigurieren von CorporateRootCA-Verteilungspunkten für CRLs und AIA über die Benutzeroberfläche

Änderungen am Sperrlisten-Verteilungspunkt und an AIA-Erweiterungen treten erst in Kraft, nachdem die CA neu gestartet wurde, und die Erweiterungen werden in ausgestellten Zertifikaten erst angezeigt, nachdem die Änderungen übernommen wurden.

Auf Computern, die unter einem Produkt aus der Windows 2000-Produktfamilie ausgeführt werden, muss ein anderes CRL- und AIA-Konfigurationsverfahren als auf Computern unter einem Produkt aus der Windows Server 2003-Produktfamilie ausgeführt werden.

Prüfen Sie vor der Änderung der CRL-Konfiguration die Standardeinstellungen.

Melden Sie sich an dem Computer mit einem Konto an, das über die Berechtigungen eines CA-Administrators verfügt.

Geben Sie dazu an der Eingabeaufforderung Folgendes ein:

certutil -getreg ca\CRLPublicationURLs

Nun wird der folgende Bericht der standardmäßigen Sperrlisten-Verteilungspunkte angezeigt. Notieren Sie diese Einstellungen für den Fall, dass Sie den ursprünglichen Zustand der CRL-Konfiguration wiederherstellen müssen.

CRLPublicationURLs REG_MULTI_SZ =
     0: 65:C:\WINDOWS\system32\CertSrv\CertEnroll\%3%8%9.crl
     CSURL_SERVERPUBLISH -- 1
     CSURL_SERVERPUBLISHDELTA -- 40 (64) 
       1: 79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10
     CSURL_SERVERPUBLISH -- 1
     CSURL_ADDTOCERTCDP -- 2
     CSURL_ADDTOFRESHESTCRL -- 4
     CSURL_ADDTOCRLCDP -- 8
     CSURL_SERVERPUBLISHDELTA -- 40 (64) 
       2: 6:http://%1/CertEnroll/%3%8%9.crl
     CSURL_ADDTOCERTCDP -- 2
     CSURL_ADDTOFRESHESTCRL -- 4
       3: 0:file://\\%1\CertEnroll\%3%8%9.crl

Wie in der Zertifikatverwendungserklärung angegeben, müssen Sie für die von dieser CA ausgestellten Zertifikate den CRL- und AIA-Verteilungspunkt konfigurieren. Gehen Sie wie folgt vor, um diese Erweiterungen für eine CA unter Windows Server 2003 zu konfigurieren:

Konfigurieren von "CorporateRootCA"-Verteilungspunkten für die CRL

Nachdem Sie alle relevanten Pfade entfernt haben, gleicht die verbleibende Liste der Sperrlisten-Verteilungspunkte der in der nachstehenden Abbildung.

Abbildung 7. Pfade von Verteilungspunkten für Zertifikatsperrlisten
Bild maximieren

Nun sollen die gewünschten Pfade der Sperrlisten-Verteilungspunkte der Liste hinzugefügt werden.

Zwecks Bereitstellung mehrerer Zugriffsprotokolle für den Abruf von CRLs werden unterschiedliche Verteilungspunkte geboten, um auch heterogene Umgebungen zu unterstützen. Beachten Sie, dass der in der folgenden Tabelle aufgeführte LDAP-Pfad Informationen über den Active Directory-Namespace der Organisation enthält. Wenn das Zertifikat mit externen Parteien ausgetauscht werden soll, müssen Sie einen neutralen Namespace definieren. In dem Beispiel in diesem Abschnitt werden die folgenden Verteilungspunkte für Zertifikatsperrlisten in der angegebenen Reihenfolge verwendet.

Tabelle 14. Liste der Sperrlisten-Verteilungspunkte für "CorporateRootCA"

Der Pfad [local] sollte auf das aktuelle Windows-Installationsverzeichnis verweisen.

Die Reihenfolge, in der die Zugriffsprotokolle ausgewählt werden sollten, basiert auf dem Zertifikattyp, der von einer CA ausgestellt wird. Ein Sperrlisten-Verteilungspunkt mit HTTP als erstem Protokoll in der Liste wird für Umgebungen empfohlen, in denen eine Sperrlistenverteilung ohne Latenz wichtig ist oder in denen die meisten Clients kein Mitglied einer Active Directory-Domäne sind. HTTP-Pfade werden generell nicht repliziert und verursachen keine Latenzprobleme, wohingegen sich ein LDAP-Verteilungspunkt in einem verteilten Verzeichnisdienst wie Active Directory befinden kann. Bei den in der Tabelle aufgeführten Sperrlisten-Verteilungspunkten werden Platzhaltertoken verwendet, die unter Platzhaltertoken für Sperrlisten-Verteilungspunkte in diesem Dokument näher erläutert werden. Weitere Informationen über die Benennung von Zertifikatsperrlisten finden Sie im Kapitel Optimale Methoden in Verbindung mit CRLs.

Konfigurieren von "CorporateRootCA"-Verteilungspunkten für den Zugriff auf Stelleninformationen

Achtung: Entfernen Sie im Verlauf des nachstehenden Verfahrens nicht den lokalen Pfad für den Zugriff auf Stelleninformationen (Authority Information Access - AIA). Andernfalls ist der lokale Pfad nicht Bestandteil der AIA-Erweiterung von ausgestellten Zertifikaten.

Konfigurieren des Sperrlisten-Verteilungspunktes und des AIA-Sperrlisten-Verteilungspunktes von CorporateRootCAmithilfe einer Stapelverarbeitungsdatei

Der Pfad zum Sperrlisten-Verteilungspunkt wird als mehrwertiges Attribut in der Registrierung gespeichert. Sie können den geeigneten Wert auch mit dem Dienstprogramm Certutil.exe festlegen. Dieses Verfahren ist mit den Schritten vergleichbar, die unter Konfigurieren von "CorporateRootCA"-Verteilungspunkten für CRLs und AIA über die Benutzeroberfläche an früherer Stelle in diesem Dokument aufgeführt sind. Gehen Sie zum Konfigurieren des Pfades zum Sperrlisten-Verteilungspunkt und zu AIA für eine CA unter Windows Server 2003 mit Certutil.exe wie in diesem Abschnitt beschrieben vor.

Wichtig: Da Variablen mit Prozentzeichen (%) in Stapelverarbeitungsdateien und an der Eingabeaufforderung anders als auf der Konfigurationsbenutzeroberfläche verarbeitet werden, müssen Sie die Notation %% verwenden, wenn Sie das Beispielskript in diesem Abschnitt als Batch- oder Stapelverarbeitungsdatei ausführen möchten. Wenn Certutil.exe über die Eingabeaufforderung aufgerufen wird, ersetzen Sie %% durch ein einzelnes %.

Certutil.exe interpretiert ein mehrwertiges Attribut, wenn Sie \n als Teil der Wertzeichenfolge verwenden. Wenn ein mehrwertiges Attribut nur einen Wert enthält, vergewissern Sie sich, dass \n als letztes Zeichen der Wertzeichenfolge angehängt wird. Andernfalls wird ein Zeichenfolgenwert erstellt, der von der CA möglicherweise nicht erkannt wird. Geben Sie für weitere Informationen certutil.exe -setreg -? an der Eingabeaufforderung ein.

certutil -setreg CA\CRLPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://www. 
contoso.com/pki/%%3%%8%%9.crl\n10:LDAP:///CN=%%7%%8,CN=%%2,CN=CDP,CN
=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:LDAP:///CN
=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://www
.contoso.com/pki/%%1_%%3%%4.crt"

certutil -setreg policy\RevocationCRLURL
"http://www.contoso.com/pki/%%3%%8.crl\n"
certutil -setreg policy\LDAPRevocationCRLURL
"ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key
Services,CN=Services,%%6?certificateRevocationList?base?objectclass=
cRLDistributionPoint\n"
certutil -setreg policy\FileRevocationCRLURL "\n"
certutil -setreg policy\IssuercertURL
"http://www.contoso.com/%%1_%%3%%4.crt\n"
certutil -setreg policy\LDAPIssuercertURL
"ldap:///CN=%%7,CN=AIA,CN=Public Key
Services,CN=Services,%%6?cACertificate?base?objectclass=
certificationAuthority\n"
certutil -setreg policy\FileIssuercertURL "\n"

Überprüfen der CRL- und AIA-Konfiguration von "CorporateRootCA"

Da die Konfiguration der Sperrlisten- und AIA-Verteilungspunkte äußerst wichtig ist, sollten Sie die Konfiguration unbedingt überprüfen.

CACertPublicationURLs REG_MULTI_SZ =
    0: 1:D:\WINDOWS\system32\CertSrv\CertEnroll\%1_%3%4.crt
    CSURL_SERVERPUBLISH -- 1
    1: 2:ldap:///CN=%7,CN=AIA,CN=Public Key
Services,CN=Services,%6%11
    CSURL_ADDTOCERTCDP -- 2
    2: 2:http://www.contoso.com/pki/%1_%3%4.crt
    CSURL_ADDTOCERTCDP -- 2

Konfigurieren des Veröffentlichungsintervall für Sperrlisten über die Benutzeroberfläche

Nach der Festlegung des Sperrlisten-Verteilungspunktes müssen Sie das Veröffentlichungsintervall für Sperrlisten konfigurieren. Gehen Sie zum Veröffentlichen des Veröffentlichungszeitplanes wie folgt vor:

Konfigurieren der Sperrlisten-Veröffentlichung über eine Stapelverarbeitungsdatei

Sie können die Informationen zum Veröffentlichungszeitplan der CRL mithilfe des Dienstprogramms Certutil.exe in der Registrierung konfigurieren. Gehen Sie zum Konfigurieren des Veröffentlichungszeitplans für die CRL mithilfe von Certutil.exe wie im folgenden Abschnitt beschrieben vor. Beachten Sie, dass dieses Konfigurationsskript für eine CA unter Windows 2000 verwendet wird .

certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
net stop certsvc
net start certsvc

Verwenden Sie für eine Windows Server 2003-CA die folgenden Schritte:

certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
net stop certsvc
net start certsvc

Festlegen der Gültigkeitsdauer für von der Offline-Stammzertifizierungsstelle ausgestellte Zertifikate

Die Gültigkeitsdauer von Zertifikaten, die von einer eigenständigen CA unter Windows ausgestellt werden, beträgt standardmäßig ein Jahr. Da dieser Wert ggf. nicht den Anforderungen Ihrer Organisation entspricht, müssen Sie einen Registrierungsschlüssel festlegen, um den Standardwert zu ändern

Hinweis: Die Gültigkeitsdauer des Zertifikats der Stammzertifizierungsstelle wird bei der Einrichtung und bei der Erneuerung des CA-Zertifikats über den Wert gesteuert, der in der Datei CAPolicy.inf angegeben wurde. Der in diesem Abschnitt erläuterte Registrierungswert hat keinen Einfluss auf die Gültigkeitsdauer des Stammzertifikats.

Diese Einstellungen gelten für eine CA unter Windows 2000:

certutil -setreg ca\ValidityPeriodUnits 10 
certutil -setreg ca\ValidityPeriod "Years" 
net stop certsvc 
net start certsvc

Weitere Informationen darüber, wie Zertifikatanforderungen die Gültigkeitsdauer eines Zertifikats steuern können, finden Sie unter Steuern der Gültigkeitsdauer von Zertifikaten mit Zertifikatanforderungen in diesem Dokument.

Weitere Informationen über das Ändern des Ablaufdatums von Zertifikaten, die von einer CA unter Windows 2000 ausgegeben werden, finden Sie unter HOW TO: Change the Expiration Date of Certificates Issued by a Windows 2000 Certificate Authority (englischsprachig) in der Microsoft Knowledge Base.

Erneutes Veröffentlichen der Zertifikatsperrliste von "CorporateRootCA"

Nachdem die Erweiterungen der Sperrlisten-Verteilungspunkte auf der CA aktualisiert wurden, müssen neue Sperrlisten veröffentlicht werden, um sicherzustellen, dass alle Clients in der Lage sind, auf die aktuellsten Sperrlisteninformationen zuzugreifen. Die Veröffentlichung kann über MMC oder unter Verwendung von Certutil.exe über die Eingabeaufforderung erfolgen, wobei die Ergebnisse die gleichen sind.

Erneutes Veröffentlichen der Sperrliste mithilfe von MMC

Gehen Sie wie in diesem Abschnitt beschrieben vor, um eine Zertifikatsperrliste für eine CA unter Windows Server 2003 oder unter Windows 2000 erneut zu veröffentlichen. Das erneute Veröffentlichen der CRL ist wichtig, da angepasste Konfigurationsparameter wie DSConfigDN als Attribute in die CRL eingeschlossen werden. Darüber hinaus haben die Eigenschaften der CRL auch Auswirkungen auf deren Veröffentlichung.

Erneutes Veröffentlichen der Sperrliste über die Eingabeaufforderung

Geben Sie zum Veröffentlichen der Sperrliste an der Eingabeaufforderung certutil -CRL ein, und drücken Sie die EINGABETASTE. Mit diesem Befehl wird die Sperrliste unter dem von Ihnen konfigurierten Pfad veröffentlicht.

Überprüfen der veröffentlichten Sperrliste

Es gibt zwei Attribute, die nach der Veröffentlichung der CRL geprüft werden müssen: die Veröffentlichungszeit und das Attribut Veröffentlichte Sperrlistenstandorte. Bei der Überprüfung der Veröffentlichungszeit der CRL überprüfen Sie außerdem, ob im konfigurierten Zeitplan die richtige CRL für die Veröffentlichung festgelegt wurde. Darüber hinaus müssen Sie sich vergewissern, dass der Registrierungswert DSConfigDN ordnungsgemäß gesetzt wurde und dass sich dieser Registrierungswert in der CRL befindet.

Ermitteln des Namens der aktuellsten Sperrliste

Published CRL Locations
  [1]Locations   Distribution Point Name: 
    Full Name: 
     URL=ldap:///CN=CorporateRootCA,CN=concorp-ca-
00,CN=CDP,CN=Public%20Key%20Services,CN=Services,DC=Unavailable
ConfigDN?certificateRevocationList?base?objectClass=cRLDistributionPoint

Wenn die Ausgabe DC=UnavailableConfigDN lautet, finden Sie entsprechende Informationen zur Korrektur dieses Verhaltens unter Zuordnen des Active Directory-Namespace oder Neuveröffentlichen der Sperrliste von "CorporateRootCA" weiter oben in diesem Dokument.

Bei einer einwandfrei konfigurierten Sperrliste muss die Ausgabe wie folgt lauten:

Published CRL Locations
  [1]Locations
   Distribution Point Name: 
    Full Name: 
      URL=ldap:///CN=CorporateRootCA,CN=concorp-ca-00,CN=CDP,CN
=Public%20Key%20Services,CN=Services,CN=Configuration,DC=concorp,
DC=contoso,DC=c
om?certificateRevocationList?base?objectClass=cRLDistributionPoint

Vorsicht: Vergewissern Sie sich, dass der kursiv gedruckte Text mit dem Wert der DSConfigDN-Registrierungswerte übereinstimmt. Überprüfen Sie weiterhin, ob die objectClass-Komponente des LDAP-Pfads richtig definiert ist

Fertigstellen der CA-Konfiguration

Nachdem die in den vorherigen Abschnitten beschriebenen Schritte ausgeführt wurden, ist die Zertifizierungsstelle funktionsbereit und in der Lage, Zertifikate auszustellen.

Wenn Sie anstelle einer Windows Server 2003-Zertifizierungsstelle eine Windows 2000-Zertifizierungsstelle installieren, sollten Sie außerdem die zusätzlichen Konfigurationsschritte ausführen, die unter Deaktivieren von Name und Seriennummer des Ausstellers weiter unten in diesem Dokument beschrieben werden.

Zum Seitenanfang

Eigenständige Offline-Zwischenzertifizierungsstelle ("IntermediateCA1")

Die eigenständige Offline-Zwischenzertifizierungsstelle wird in diesem Dokument "IntermediateCA1" bezeichnet.

Eine eigenständige Offline-Zwischenzertifizierungsstelle bildet einen Bestandteil einer dreistufigen Topologie und dient hauptsächlich dazu, die Flexibilität in einer Organisation zu erweitern. IntermediateCA1 ist erforderlich, um Zertifikate für Unternehmenszertifizierungsstellen auszustellen, die Authentifizierungszertifikate ausschließlich gemäß der Zertifikatverwendungserklärung registrieren.

Wenn eine zweistufige Topologie implementiert werden soll, können Sie diesen Abschnitt überspringen und mit dem Abschnitt Ausstellende Online-Unternehmenszertifizierungsstellen ("CorporateEnt1CA") fortfahren.

Installationsvoraussetzungen

Um die eigenständige Offline-Zwischenzertifizierungsstelle einwandfrei zu installieren und zu konfigurieren, ist Folgendes erforderlich:

Bei IntermediateCA1 muss es sich um ein Arbeitsgruppenmitglied handeln, da sie nicht an das Netzwerk angeschlossen und nicht mit einem Domänencontroller verbunden ist. Darüber hinaus muss sichergestellt sein, dass der Computername dieses Server im Netzwerk der Organisation eindeutig ist, da der Computername Bestandteil der CA-Konfigurationsinformationen ist, die in Active Directory veröffentlicht werden. (Weitere Informationen finden Sie unter Importieren der Zertifikate und Sperrlisten der übergeordneten Zertifizierungsstelle in Active Directory weiter unten in diesem Dokument.) Melden Sie sich an dem Computer an, der Offline-Zwischenzertifizierungsstelle wird, geben Sie an einer Eingabeaufforderung den folgenden Befehl ein, damit der Computer ein Arbeitsgruppenmitglied wird, und drücken Sie dann die EINGABETASTE:

net config workstation

Ändern Sie eine Domänenmitgliedschaft ggf. in eine Arbeitsgruppenmitgliedschaft.

Installieren eines Hardwaresicherheitsmoduls auf "IntermediateCA1"

Überprüfen Sie vor Beginn der CA-Installation anhand des Installationshandbuchs des Herstellers, ob das Hardwaresicherheitsmodul (HSM) ordnungsgemäß eingerichtet ist. Weitere Informationen finden Sie unter Installieren eines Hardwaresicherheitsmoduls für eine Offline-Stammzertifizierungsstelle in diesem Dokument.

Vorbereiten der Datei "CAPolicy.inf" für "IntermediateCA1"

Vor der CA-Installation muss die Datei CAPolicy.inf vorhanden sein. Die Hauptaufgabe der Datei CAPolicy.inf besteht darin, alle Ausstellungsrichtlinien auf der Zwischenebene zuzulassen. Eine Stammzertifizierungsstelle stellt ein untergeordnetes CA-Zertifikat immer so aus, dass alle Ausstellungsrichtlinien zugelassen sind. Auf der Ebene der Zwischenzertifizierungsstelle muss dieses Attribut explizit festgelegt werden, da sonst alle Anwendungsrichtlinien, aber keine Ausstellungsrichtlinien zugelassen würden. Eine ausstellende Zertifizierungsstelle kann keine Ausstellungsrichtlinie definieren, wenn das CA-Zertifikat keine Ausstellung von Zertifikaten zulässt. Weitere Informationen finden Sie in Kapitel 4.2.1.5, Certificate Policies, (englischsprachig) auf der Internet FAQ Archives-Website.

Eine eigenständige Zertifizierungsstelle kann über Zertifikatvorlagen keine Richtlinien definieren, da es sich hierbei um ein Feature anpassbarer V2-Vorlagen handelt. Eine eigenständige Zertifizierungsstelle kann keine V2-Vorlagen verwenden, um Zertifikate auszustellen. Die Datei CAPolicy.inf definiert die Richtlinie, die für alle Zertifikate gilt, die von der Zwischenzertifizierungsstelle ausgestellt werden.

Im Vergleich zur Konfiguration der CorporateRootCA benötigt die Datei CAPolicy.inf keine vordefinierten CRL- und AIA-Erweiterungen, da diese Konfigurationsattribute von der übergeordneten Zertifizierungsstelle übernommen werden, die das untergeordnete CA-Zertifikat ausstellt. Beachten Sie, dass für die einwandfreie Verarbeitung der Datei CAPolicy.inf bestimmte Voraussetzungen erfüllt sein müssen.

Führen Sie die folgenden Schritte durch:

Abrufen von Zertifikat und Sperrliste von "CorporateRootCA"

Bevor Sie den IntermediateCA1-Computer einrichten können, müssen das Zertifikat der Stammzertifizierungsstelle und die aktuellste Sperrliste installieren, die CorporateRootCA bereitstellt, da IntermediateCA1 die Vertrauensstellung des Stammzertifikats während der Installation überprüft.

Sie müssen sich das Zertifikat der übergeordneten Zertifizierungsstelle u. U. einmalig manuell besorgen. Nach einer Erneuerung der Stammzertifizierungsstelle muss erneut ein CA-Zertifikat in den Zertifikatspeicher von IntermediateCA1 importiert werden. Da die Stammzertifizierungsstelle und die Zwischenzertifizierungsstelle normalerweise nicht über das Netzwerk verbunden und offline sind, kann das Zertifikat der Stammzertifizierungsstelle der Zwischenzertifizierungsstelle nicht über das Netzwerk zur Verfügung gestellt werden.

Im Vergleich zum CA-Zertifikat, das einen langen Gültigkeitszeitraum (mehrere Jahre) aufweisen kann, muss der Import der Sperrliste der übergeordneten Offline-Zertifizierungsstelle in regelmäßigen Zeitabständen erfolgen, die dem Veröffentlichungsintervall der Sperrliste entsprechen. (Weitere Informationen finden Sie im Abschnitt Konfigurieren des Veröffentlichungsintervalls für Sperrlisten über die Benutzeroberfläche weiter oben in diesem Dokument.) Sie müssen die Sperrliste der übergeordneten Offline-Zertifizierungsstelle regelmäßig importieren, weil die Offline-Zertifizierungsstelle die Sperrlisten nicht automatisch über das Netzwerk abrufen kann. Sie müssen eine Kopie der aktuellsten Sperrliste im lokalen Zertifikatspeicher einer Offline-Zertifizierungsstelle installieren.

Sperrliste und CA-Zertifikat werden in den folgenden Konfigurationsschritten auf einer Diskette an den Computer der untergeordneten Zertifizierungsstelle übertragen. Zertifikat und Sperrliste stehen auf dem CorporateRootCA-Computer im Dateiformat zur Verfügung.

So rufen Sie CA-Zertifikat und Sperrliste ab:

Sie können Zertifikate auch über das MMC-Snap-In Zertifizierungsstellen exportieren. Weitere Informationen hierzu finden Sie unter Exportieren des Offline-Zwischenzertifikats auf der Stammzertifizierungsstelle in diesem Dokument.

Importieren von Zertifikat und Sperrliste der Stammzertifizierungsstelle auf die Zwischenzertifizierungsstelle

Das Zertifikat der Stammzertifizierungsstelle wird bei der Installation der Zwischenzertifizierungsstelle benötigt und muss vor der Einrichtung der Zwischenzertifizierungsstelle im Zertifikatspeicher der Zwischenzertifizierungsstelle installiert werden. Mit dem Befehl Certutil.exe können Sie CA-Zertifikate in den Zertifikatspeicher importieren (siehe Beschreibung weiter unten in diesem Abschnitt). Die Zertifikate und Sperrlisten werden dabei an die richtige Position importiert.

Wenn das Zertifikat von CorporateRootCA erneuert wurde, müssen Sie unbedingt alle CA-Zertifikate und die zugehörigen Sperrlisten importieren. Diese können anhand der Versionsnummer identifiziert werden, da CA-Zertifikat und Sperrliste die gleiche Versionsnummer aufweisen.

Beispiel

Falls auf CorporateRootCA ein Zertifikat aktiv ist, das während der Installation generiert wurde, müssen die folgenden Dateien in die Zwischenzertifizierungsstelle importiert werden.

Tabelle 18: Zu importierende Dateien bei einem neuen Zertifikat

Wie bereits oben erwähnt, müssen Sie CA-Zertifikat und Sperrliste von CorporateRootCA importieren, nachdem das Zertifikat der Stammzertifizierungsstelle erneuert wurde. Beachten Sie im folgenden Beispiel, dass Windows einen inkrementellen Wert zum Dateinamen hinzufügt, wenn mehrere CA-Zertifikate und Sperrlisten vorhanden sind. Wenn CorporateRootCA beispielsweise zwei Mal erneuert wurde, müssen Sie die folgenden Dateien in IntermediateCA1 importieren.

Tabelle 19: Zu importierende Dateien bei einem zuvor verwendeten Zertifikat

Importieren von Zertifikat und Sperrliste der Stammzertifizierungsstelle über MMC

In diesem Abschnitt wird beschrieben, wie ein Zertifikat über das MMC-Snap-In Zertifikate importiert werden kann. Die folgenden Schritte sollen lediglich veranschaulichen, wie Zertifikat und Sperrliste der Stammzertifizierungsstelle über das MMC-Snap-In auf eine Zwischenzertifizierungsstelle importiert werden können.

Es ist einfacher, die CA-Zertifikate über die Eingabeaufforderung zu importieren. Die entsprechende Vorgehensweise wird weiter unten in diesem Abschnitt beschrieben.

Nach Abschluss dieses Verfahren sind CA-Zertifikat und Sperrliste im Zertifikatspeicher des lokalen Computers gespeichert.

Hinweis: Sie müssen die Schritte in diesem Abschnitt wiederholen, wenn Sie weitere Sperrlisten und Zertifikate importieren möchten. Dies ist notwendig, wenn das CorporateRootCA-Zertifikat erneuert oder eine neue Version der Sperrliste veröffentlicht wurde.

Suchen eines Zertifikats im Zertifikatspeicher

Wenn das Zertifikat in den falschen Zertifikatspeicher importiert wurde, können Sie die Option Zertifikate suchen verwenden.

Sie können mit der Option Zertifikate suchen auch doppelte Zertifikate ermitteln, die den verschiedenen Zertifikatspeichern vorhanden sind. Wenn das Zertifikat einwandfrei eingerichtet wurde, ist das Zertifikat nur ein Mal vorhanden. Entfernen Sie doppelte Zertifikate, wenn das gleiche Zertifikat mehrmals vorhanden ist, und überprüfen Sie, ob das Zertifikat im richtigen Container gespeichert ist. Es muss unbedingt bekannt sein, welches Zertifikat zu welchem Zertifikatspeicher gehört. Weitere Informationen zum Überprüfen von CA-Zertifikaten finden Sie im Abschnitt Beziehung zwischen Konfigurationscontainer und Zertifikatspeicher in diesem Dokument. Weitere Informationen zu Stammzertifikaten finden Sie im Artikel Vertrauenswürdige Stammzertifikate, die von Windows Server 2003, Windows XP und Windows 2000 benötigt werden (maschinelle Übersetzung) auf der Microsoft-Website sowie im Artikel Vertrauenswürdiges Root-Zertifikat aus der Liste der vertrauenswürdigen Stammzertifizierungsstellen entfernen in der Microsoft Knowledge Base.

So suchen Sie ein Zertifikat im Zertifikatspeicher:

Bei einer erfolgreichen Suche wird eine Liste der Zertifikate, die die Suchkriterien erfüllen, mit dem entsprechenden Zertifikatspeicher angezeigt.

Importieren von Zertifikat und Sperrliste der Stammzertifizierungsstelle über eine Batchdatei in eine Zwischenzertifizierungsstelle

So importieren Sie Zertifikat und Sperrliste der Stammzertifizierungsstelle über eine Batchdatei:

Dadurch werden alle Zertifikate und die neueste Sperrliste im entsprechenden CryptoAPI-Speicher gespeichert. (Die Schleife um den Befehl certutil vereinfacht den Importvorgang, weil auf der Diskette u. U. mehrere Zertifikate oder Sperrlisten vorhanden sind, die importiert werden müssen.) Der optionale Parameter -f erzwingt ein Überschreiben des Zertifikats, falls das Zertifikat bereits zum Speicher hinzugefügt wurde.

In den Zertifikatspeicher werden nur gültige Zertifikate importiert.

Hinweis: Da es schwierig sein kann, die erforderliche Version von Zertifikat oder Sperrliste zu ermitteln, wird empfohlen bei Vorhandensein mehrerer Sperrlisten alle Sperrlisten der Stammzertifizierungsstelle zu importieren. Weitere Informationen zur Speicherung von Zertifikaten und Sperrlisten finden Sie im Abschnitt Beziehung zwischen Konfigurationscontainer und Zertifikatspeicher in diesem Dokument.

Überprüfen des Importvorgangs von Zertifikaten der Stammzertifizierungsstelle an einer Eingabeaufforderung

Nach dem Import von Zertifikat und Sperrliste der Stammzertifizierungsstelle können Sie mit dem Dienstprogramm Certutil.exe den Erfolg des Importvorgangs bestätigen. Es muss unbedingt sichergestellt sein, dass die Zertifikate im richtigen Zertifikatspeicher gespeichert wurden.

Geben Sie an einer Eingabeaufforderung den folgenden Befehl ein, um eine Liste der Zertifikate anzuzeigen, die im Zertifikatspeicher für die Stammzertifizierungsstelle gespeichert sind:

certutil -verifystore root

Die Versionsnummer wird als Bestandteil des Ausgabetextes angezeigt. Überprüfen Sie, ob Versionsnummer von CA-Zertifikat und Sperrliste übereinstimmen.

Installieren der Softwarekomponenten der Offline-Zwischenzertifizierungsstelle

Das Installationsverfahren für eine untergeordnete Zertifizierungsstelle unterscheidet sich von dem für eine Stammzertifizierungsstelle. Führen Sie die folgenden Schritte durch, um IntermediateCA1 zu installieren:

1.	Melden Sie sich an IntermediateCA1 als lokaler Administrator an. Während der CA-Installation wird dieses Konto CA-Administrator. Diese Funktion kann auch an andere Benutzerkonten delegiert werden. Weitere Informationen zu CA-Funktionen und -Berechtigungen finden Sie in der Windows Server 2003-Hilfe.
2.	Führen Sie einen der folgenden Schritte durch, um den Assistenten für Windows-Komponenten zu öffnen: Zweck Aktion Eingabeaufforderung öffnen 1. Klicken Sie auf Start und dann auf Ausführen. Geben Sie im Dialogfeld Öffnen den Befehl cmd ein, und klicken Sie dann auf OK. 2. Geben Sie an der Eingabeaufforderung sysocmgr /i:sysoc.inf ein, und drücken Sie die EINGABETASTE. Systemsteuerung öffnen 1. Klicken Sie auf Start, zeigen Sie auf Einstellungen und dann auf Systemsteuerung. Klicken Sie anschließend auf Software. 2. Klicken Sie im Dialogfeld Software auf Windows-Komponenten hinzufügen/entfernen.
3.	Aktivieren Sie das Kontrollkästchen Zertifikatdienste, und klicken Sie dann auf Weiter. Für eine einwandfreie Ausführung der Zertifikatdienste sind die folgenden Softwarekomponenten erforderlich. Webregistrierung und IIS sind optionale Komponenten auf der Windows Server 2003-Offline-Zertifizierungsstelle, die jetzt oder später mit der Zertifizierungsstelle installiert werden können. Hinweis: Wie in diesem Dokument unter Installieren der Softwarekomponenten für eine Offline-Stammzertifizierungsstelle beschrieben, ist IIS auf einer Offline-Zertifizierungsstelle nicht erforderlich. IIS kann jedoch auf dem Computer installiert werden, um Zertifikate über die Webregistrierung zu registrieren. Aus Sicherheitsgründen wird nicht empfohlen, IIS zu installieren (wird in diesem Dokument lediglich als Beispiel behandelt). Zertifikatdienste • Zertifikatdienste-CA • Webregistrierungssupport für Zertifikatdienste Internet Explorer Anwendungsserver • COM+-Netzwerkzugriff aktivieren • IIS (Internetinformationsdienste) • Gemeinsame Dateien • Internetinformationsdienste-Manager • WWW-Dienste • Active Server Pages • WWW-Dienste Eine Windows 2000-Offline-Zertifizierungsstelle setzt IIS voraus, um Offlineanforderungen erfüllen zu können. Eine Windows Server 2003-Zertifizierungsstelle kann Offline-Zertifikatanforderungen als Funktion des MMC-Snap-Ins Zertifizierungsstellen verarbeiten. Alternativ können Sie Offlineanforderungen mithilfe von Certreq.exe an einer Eingabeaufforderung einreichen.
4.	Klicken Sie auf Eigenständige untergeordnete Zertifizierungsstelle, wenn Sie aufgefordert werden, den Installationstyp auszuwählen. Aktivieren Sie dann das Kontrollkästchen Schlüsselpaar und ein Zertifizierungsstellenzertifikat mit diesen Einstellungen erstellen, und klicken Sie dann auf Weiter. Die Optionen Stammzertifizierungsstelle des Unternehmens und Untergeordnete Zertifizierungsstelle des Unternehmens stehen nicht zur Verfügung, weil der Computer kein Mitglied einer Active Directory-Domäne ist.
5.	Führen Sie einen der folgenden Schritte durch: • Wenn ein HSM installiert wurde, müssen Sie unter Kryptografiedienstanbieter den Kryptografiedienstanbieter auswählen, der bei der HSM-Installation installiert wurde. • Wenn kein HSM installiert wurde, klicken Sie in Kryptografiedienstanbieter auf Microsoft Strong Cryptographic Provider.
6.	Klicken Sie in Hashalgorithmus auf SHA-1. Die Standardeinstellung, SHA-1, ist der gebräuchlichste Hashalgorithmus mit der größten Interoperabilität, der von Anwendungen und Betriebssystemen verwendet wird.
7.	Wählen Sie unter Schlüssellänge den Eintrag 2048 aus. Die in das Feld eingegebene Schlüssellänge wird nicht überprüft. Überprüfen Sie daher, dass die Schlüssellänge mit den Anwendungen des Unternehmens und anderen PKI-Komponenten zusammenarbeiten kann.
8.	Vergewissern Sie sich, dass die beiden Kontrollkästchen Kryptografiedienstanbieter Zugriff auf Desktop gestatten und Vorhandenen Schlüssel verwenden deaktiviert sind, und klicken Sie dann auf Weiter.
9.	Geben Sie in Allgemeiner Name dieser Zertifizierungsstelle einen allgemeinen Namen für die Zertifizierungsstelle ein. Geben Sie beispielsweise IntermediateCA1 ein. Wie bei der Zertifikatverwendungserklärung müssen Sie den allgemeinen Namen (Common Name - CN) für diese Zertifizierungsstelle eingeben. Die Länge des CN darf 64 Zeichen nicht überschreiten. Sie sollten jedoch einen Namen mit maximal 51 Zeichen verwenden, um eine Verletzung der Codierungslängenregel zu vermeiden.
10.	(Optional) Geben Sie in Suffix des definierten Namens das Suffix des definierten Namens für die Zertifizierungsstelle ein, und klicken Sie dann auf Weiter. Vergewissern Sie sich ggf., dass in Suffix des definierten Namens der Name richtig eingegeben wurde, damit es im Kontext des Active Directory-Domänennamen funktioniert. Im Contoso-Szenario lautet der definierte Name DC=concorp,DC=contoso,DC=com.
11.	Der Gültigkeitszeitraum des CA-Zertifikats für eine untergeordnete Zertifizierungsstelle wird immer durch die übergeordnete Zertifizierungsstelle bestimmt. Weitere Informationen finden Sie unter Festlegen der Gültigkeitsdauer für von der Offline-Stammzertifizierungsstelle ausgestellte Zertifikate weiter oben in diesem Dokument.
12.	Wenn auf diesem Computer bereits eine Zertifizierungsstelle deinstalliert wurde, wird eine Warnmeldung mit der Bestätigung angezeigt, dass der private Schlüssel der vorherigen CA-Installation überschrieben werden soll. Sie sollten sicherstellen, dass der private Schlüssel nie mehr benötigt wird. Wenn Sie eine Sicherungskopie des Systems erstellen, steigt die Wahrscheinlichkeit, dass keine Daten verloren gehen. (Sie können anstelle einer Systemsicherung auch eine Sicherungskopie des privaten Schlüssels erstellen. Geben Sie dazu an einer Eingabeaufforderung den Befehl certutil -backupkey -? ein.) Klicken Sie auf Nein, wenn Sie sich nicht sicher sind, ob der private Schlüssel überschrieben werden soll, um die Installation abzubrechen. Wenn Sie auf Ja klicken, wird ein neuer Schlüssel generiert, der den vorhandenen Schlüssel ersetzt. Das Schlüsselpaar wird vom Kryptografiedienstanbieter generiert und in den Schlüsselspeicher des lokalen Computers geschrieben.
13.	Überprüfen Sie, ob unter Einstellungen der Zertifikatdatenbank die Ordner für Zertifikatdatenbank, Zertifikatdatenbankprotokoll und Gemeinsamer Ordner richtig eingestellt sind.
14.	(Optional) Aktivieren Sie das Kontrollkästchen Vorhandene Zertifikatdatenbank nicht löschen, um eine Zertifizierungsstelle am gleichen Speicherort zu installieren wie die vorherige Zertifizierungsstelle, und klicken Sie dann auf Weiter.
15.	Vergewissern Sie sich, dass in Gemeinsamer Ordner ein lokaler Pfad angegeben ist, wie z. B. C:\CAconfig, und klicken Sie dann auf Weiter.
16.	Legen Sie die Diskette Transfer-IntermediateCA in das Diskettenlaufwerk ein.
17.	Klicken Sie unter Anforderung eines Zertifizierungsstellenzertifikats auf Anforderung in einer Datei speichern, und geben Sie in Anforderungsdatei einen Namen für die Anforderungsdatei ein, die auf der Diskette gespeichert wird. Klicken Sie anschließend auf Weiter. Die Datei muss die Erweiterung REQ aufweisen (z. B. a:\IntermediateCA1.req).
18.	Klicken Sie in der Meldung mit dem Hinweis, dass IIS zum Fortsetzen der Installation beendet werden muss, auf Ja. Die Zwischenzertifizierungsstelle muss die Zertifikatanforderung an die übergeordnete Offline-Zertifizierungsstelle einreichen. Da der CorporateRootCA-Computer über keine Netzwerkverbindung verfügt, müssen Sie die angeforderte Datei auf Diskette übertragen. Vorsicht Achten Sie darauf, dass die Diskette verfügbar ist, bevor Sie den Vorgang fortsetzen. Wenn das Speichergerät nicht zugänglich ist, wird eine Fehlermeldung angezeigt. Die CA-Installation wird dann beendet, und die Zertifizierungsstelle muss neu installiert werden. Bevor Sie die Zertifizierungsstelle neu installieren können müssen Sie ggf. den Webregistrierungssupport für Zertifikatdienste deinstallieren.
19.	Der Assistent für Windows-Komponenten schließt die Konfiguration der Zertifikatdienste ab. Wenn das CA-Zertifikat ein signiertes untergeordnetes CA-Zertifikat von der übergeordneten Zertifizierungsstelle erhalten hat, wird im Assistenten die Meldung angezeigt, dass die Installation fertig gestellt wurde. Vergewissern Sie sich, dass das lokale Speichergerät verfügbar ist, damit die Anforderungsdatei gespeichert werden kann, und klicken Sie dann auf OK.
20.	Klicken Sie auf Ja, um die ASP-Seiten zu aktivieren, die für die Webregistrierungsdienste benötigt werden. Bei dieser Konfiguration wird IIS aus Gründen der Veranschaulichung installiert. Die ASP-Seiten werden jedoch standardmäßig nicht installiert. Die CA-Installation bietet daher die Möglichkeit, die ASP-Seiten automatisch zu aktivieren. Wenn Sie auf Nein klicken, können Sie die ASP-Seiten aktivieren, indem Sie später an einer Eingabeaufforderung certutil -vroot eingeben. Abbildung 8: Active Server Pages aktivieren Bild maximieren
21.	Klicken Sie auf Fertig stellen, nachdem die Dateien vom Assistenten kopiert wurden, und klicken Sie dann auf Schließen.
22.	Entnehmen Sie die Diskette Transfer-IntermediateCA aus dem Laufwerk, und bringen Sie die Diskette zur übergeordneten Zertifizierungsstelle (CorporateRootCA).

Überprüfen der Zertifikatanforderung

Bevor die Zertifikatanforderung an die übergeordnete Zertifizierungsstelle eingereicht wird, müssen Sie die Richtigkeit der Richtlinienkennung überprüfen, die über CAPolicy.inf in der CA-Konfiguration festgelegt wurde. Wenn die Syntax der Datei CAPolicy.inf nicht richtig ist, fehlen in der Anforderungsdatei u. u. bestimmte Konfigurationsinformationen. Um festzustellen, ob alle Konfigurationsinformationen ordnungsgemäß in der Zertifikatanforderung enthalten sind, müssen Sie die Anforderungsdatei überprüfen. Geben Sie dazu an einer Eingabeaufforderung certutilAnforderungsdatei ein, und drücken Sie die EINGABETASTE. Dabei steht Anforderungsdatei für die Anforderungsdatei einschließlich Pfad, die auf der Diskette gespeichert wurde.

Daraufhin wird eine ähnliche Ausgabe wie die folgende angezeigt: Überprüfen Sie die Richtigkeit des Abschnitts Certificate Policies sowie der anderen Informationen in der Datei CAPolicy.inf.

Wenn der Abschnitt Certificate Policies in der Zertifikatanforderung nicht angezeigt wird, finden Sie entsprechende Informationen im Abschnitt Vorbereiten der Datei "CAPolicy.inf" für IntermediateCA1 in diesem Abschnitt. Korrigieren Sie die Syntax in der Datei CAPolicy.inf, und wiederholen Sie die Installation der untergeordneten Zertifizierungsstelle.

Attribute[2]: 1.2.840.113549.1.9.14 (Certificate Extensions)
    Value[2][0]: 
    Unknown Attribute type
Certificate Extensions: 6
    1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
    CA Version
        V0.0
    2.5.29.14: Flags = 0, Length = 16
    Subject Key Identifier
        84 b9 bf 37 a7 9b 0d 75 28 62 00 27 bf 72 da d0 66 a5 79 e8
    2.5.29.32: Flags = 0, Length = 139
    Certificate Policies
        [1]Certificate Policy: 
             Policy Identifier=1.3.6.1.4.1.311.21.43
             [1,1]Policy Qualifier Info: 
                  Policy Qualifier Id=User Notice
                  Qualifier: 
                       Notice Text=Legal policy statement text. 
        [2]Certificate Policy: 
             Policy Identifier=1.3.6.1.4.1.311.21.47
             [2,1]Policy Qualifier Info: 
                  Policy Qualifier Id=CPS
                  Qualifier: 
                       http://www.contoso.com/pki/LimitedUsePolicy.htm
             [2,2]Policy Qualifier Info: 
                  Policy Qualifier Id=CPS
                  Qualifier: 
                       ftp://ftp.contoso.com/pki/LimitedUsePolicy.txt
             [2,3]Policy Qualifier Info: 
                  Policy Qualifier Id=User Notice
                  Qualifier: 
                       Notice Text=Limited use policy statement text.

Verarbeiten der Zertifikatanforderung mit der Stammzertifizierungsstelle über das MMC-Snap-In

Die Zertifikatanforderung der untergeordneten Zertifizierungsstelle, die auf der Diskette Transfer-IntermediateCA gespeichert ist, muss von der übergeordneten Zertifizierungsstelle (CorporateRootCA) signiert werden.

Sie können eine Anforderung über das MMC-Snap-In Zertifizierungsstelle oder die Webregistrierungsseite der übergeordneten Windows Server 2003-Zertifizierungsstelle an eine Offline-Zertifizierungsstelle einreichen. Sie können die Anforderung auch durch Eingeben von certreq.exe -submit an einer Eingabeaufforderung einreichen. Mit allen Methoden können Sie eine Zertifikatanforderung einreichen, die in einer Anforderungsdatei (REQ-Datei) gespeichert wurde. In diesem Abschnitt wird die erste Methode beschrieben, bei der das MMC-Snap-In Zertifizierungsstellen verwendet wird. Weitere Informationen zur Verwendung der Webregistrierungsseite finden Sie unter Verarbeiten der Zertifikatanforderung mit der übergeordneten Offline-Zertifizierungsstelle ("IntermediateCA1") über Webregistrierungssupport weiter unten in diesem Dokument.

Vorsicht Wenn eine frühere CA-Installation nicht funktioniert hat und die Installation wiederholt wird, dürfen Sie nicht die Anforderungsdatei der früheren CA-Installation verwenden, da dieser Schlüsseldaten zugeordnet sind, die nicht zu der aktuell installierten Zertifizierungsstelle passen.

Nachdem eine Zertifizierungsstelle eingerichtet wurde, werden die Schlüsseldaten generiert und die Zertifikatanforderung an die übergeordnete Zertifizierungsstelle eingereicht. Die Beziehung zwischen Schlüsseldaten und Zertifikat wird über das Attribut AKI certificate verwaltet. Damit die Zuordnung von Schlüsselpaar und Zertifikatanforderung der Zertifizierungsstelle zueinander passt, muss bei der Einrichtung einer Zertifizierungsstelle eine eindeutige Anforderungsdatei verwendet werden.

Überprüfen des "IntermediateCA1"-Zertifikats

Um sicherzustellen, dass das für IntermediateCA1 ausgestellte Zertifikat die richtigen Zertifikateigenschaften aufweist, überprüfen Sie das ausgestellte Zertifikat:

Hinweis: Sie können das Zertifikat auch überprüfen, nachdem es in eine Datei exportiert wurde. Um die Zertifikatinformation einer PKCS #7-, DER- oder Base64-codierten Zertifikatdatei anzuzeigen, geben Sie an einer Eingabeaufforderung den Namen ZertDatei ein und drücken die EINGABETASTE. Dabei steht ZertDatei für den Pfad und den Dateinamen der Zertifikatdatei.

Exportieren des Offline-Zwischenzertifikats auf der Stammzertifizierungsstelle

Wenn das für die Zwischenzertifizierungsstelle ausgestellte Zertifikat die Überprüfung bestanden hat, exportieren Sie das Zertifikat auf der Stammzertifizierungsstelle.

Hinweis: Da der Zertifikatexport-Assistent den vollständigen Pfad der exportierten Datei einbeziehen kann, sollten Sie diese Methode anstelle der binären Exportmethode verwenden, die nur ein einzelnes Zertifikat exportiert.

Installieren des Zertifikats auf "IntermediateCA1"

Sie haben jetzt die Anforderung, die an die Stammzertifizierungsstelle gesendet wurde verarbeitet und auf der Diskette Transfer-IntermediateCA gespeichert. Sie müssen jetzt das signierte untergeordnete CA-Zertifikat für IntermediateCA1 installieren. Sie können das CA-Zertifikat über einen Befehl an einer Eingabeaufforderung oder im MMC-Snap-In Zertifizierungsstellen installieren. Die untergeordnete CA-Zertifikatanforderung wird von der übergeordneten Zertifizierungsstelle nur akzeptiert, wenn in der Anforderung die Signatur der anfordernden Zertifizierungsstelle enthalten ist.

Überprüfen der "IntermediateCA1"-Zertifikatvertrauenskette

Überprüfen Sie die Zertifikatvertrauenskette, um unerwartete oder unbeabsichtigte Verhalten zu vermeiden. Sie müssen die Überprüfung der Vertrauenskette an einer Eingabeaufforderung durchführen, da der Vertrauenspfad, der im MMC-Snap-In Zertifizierungsstellen angezeigt wird, eine andere Implementierung für die Kettenbildung verwendet.

Dieser Befehl erzeugt u. U. eine umfangreiche Ausgabe. Wenn dwErrorStatus nicht den Wert Null aufweist, ist bei der Zertifikatüberprüfung ein Fehler aufgetreten. Sie müssen daher in jeder erzeugten Zeile überprüfen, ob dwErrorStatus Null (0) ist.

Sie können auch folgenden Befehl verwenden:

certutil -verifya:\ CAZertDatei.crt | findstr /c:dwErrorStatus

Dabei steht CAZertDatei für den Pfad und Namen der Datei.

Die Ausgabe einer fehlerfreien CA-Zertifikatüberprüfung sieht ungefähr wie folgt aus:

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0 
CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0

Bei der Zertifikatüberprüfung werden alle Sperrlisten abgerufen, die für die Überprüfung der Zertifikate erforderlich sind. Nach der Überprüfung sind im Ordner für temporäre Internet Explorer-Dateien des Clients zwischengespeicherte Kopien der Sperrlisten verfügbar.

Installieren des Zertifikats auf "IntermediateCA1"

Installieren Sie das CA-Zertifikat, nachdem überprüft wurde, dass die Zertifikatvertrauenskette einwandfrei gebildet werden kann.

Setzen Sie die Installation fort, indem Sie die im Abschnitt Installationsbereinigung dieses Dokuments beschriebenen Schritte ausführen.

Installieren des Zertifikats auf "IntermediateCA1"

So installieren Sie das Zertifikat an einer Eingabeaufforderung:

Installationsbereinigung

Aus Sicherheitsgründen sollten Sie die Zertifikatanforderungsdatei auf der Diskette Transfer-IntermediateCA löschen, mit der das CA-Zertifikat generiert wurde.

Konfigurieren von "IntermediateCA1"

Nachdem die Offline-Zertifizierungsstelle mit den Schritten in den vorangegangenen Abschnitten konfiguriert wurde, können Sie die restlichen Schritte für IntermediateCA1 mit einem Batchdateiskript ausführen. Der Unterschied der Konfiguration der Stammzertifizierungsstelle und der untergeordneten Zertifizierungsstelle besteht im Gültigkeitszeitraum der ausgestellten Zertifikate. So konfigurieren Sie die untergeordnete Zertifizierungsstelle:

Einbeziehen der CA-Richtlinie in Zertifikatanforderungen

Mit den Optionen für CA-Ausstellungs- und Anwendungsrichtlinien kann die CA-Ebene festgelegt werden, auf der die Richtlinien angewendet werden. Wenn Sie beabsichtigen, in einer Zertifizierungsstelle eine Ausstellererklärung zu konfigurieren, müssen Sie die übergeordnete Zertifizierungsstelle so konfigurieren, dass in den ausgestellten Zertifikaten Informationen zur CA-Richtlinie enthalten sind. Weitere Informationen finden Sie unter CAPolicy.inf-Beispieldatei für "IntermediateCA1" weiter unten in diesem Dokument.

Wenn dieser Konfigurationsschritt übergangen wird, akzeptiert eine Zwischenzertifizierungsstelle keine CA-Zertifikatrichtlinien von den untergeordneten Zertifizierungsstellen und lässt auch keine solchen Richtlinien zu. Bei Bedarf können Sie diesen Konfigurationsschritt dann ausführen, wenn eine Ausstellungs- oder Anwendungsrichtlinie in eine Zertifikatanforderung einer untergeordneten Zertifizierungsstelle aufgenommen werden soll.

Geben Sie an einer Eingabeaufforderung die folgenden Befehle ein, um in ausgestellte Zertifikate eine Richtlinie einzubeziehen:

certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
certutil -shudown
net start certsvc

Sie können die Einstellung mit den folgenden Befehlen deaktivieren: certutil -v -setreg policy\EnableRequestExtensionlist "-2.5.29.32"

certutil -shudown
net start certsvc

Überprüfen der "IntermediateCA1"-Konfiguration

Nachdem die in den vorherigen Abschnitten beschriebenen Schritte ausgeführt wurden, muss überprüft werden, ob die Zertifizierungsstelle einwandfrei konfiguriert und für den Produktionsbetrieb bereit ist. Sie sollten die in den folgenden Abschnitten dieses Dokuments beschriebenen Überprüfungsschritte durchführen, da sie genauso wie für eine Stammzertifizierungsstelle ebenfalls für die Zwischenzertifizierungsstelle zutreffen:

Fertigstellen der CA-Konfiguration

Nachdem die in den vorherigen Abschnitten dieses Dokuments beschriebenen Schritte ausgeführt wurden, ist die Zwischenzertifizierungsstelle funktionsbereit und in der Lage, Zertifikate auszustellen.

Wenn Sie anstelle einer Windows Server 2003-Zertifizierungsstelle eine Windows 2000-Zertifizierungsstelle installiert haben, sollten Sie außerdem die zusätzlichen Konfigurationsschritte ausführen, die unter Deaktivieren von Name und Seriennummer des Ausstellers in diesem Dokument beschrieben werden.

Zum Seitenanfang

Eigenständige Offline-Zwischenzertifizierungsstelle ("CorporateSub2CA")

In PKI-Beispieltopologie wurden zwei getrennte eigenständige Offline-Zwischenzertifizierungsstellen verwendet, die Flexibilität für Organisation und Sicherheit bieten. Die Installationsschritte für CorporateSub2CA weisen hohe Ähnlichkeit mit denen für IntermediateCA1 auf. Die einzigen Unterschiede liegen abhängig von den Richtlinien, die in der Zertifikatverwendungserklärung der Organisation festgelegt wurden, in einigen Konfigurationsparametern.

Installieren Sie IntermediateCA2 für dieses Beispiel mit den gleichen Installationsschritten wie für IntermediateCA1.

Zum Seitenanfang

Ausstellende Online-Unternehmenszertifizierungsstellen ("CorporateEnt1CA")

Die ausstellende Online-Unternehmenszertifizierungsstelle wird in diesem Dokument als "CorporateEnt1CA" bezeichnet. Der Zweck einer Unternehmenszertifizierungsstelle besteht darin, die Registrierung ausgestellter Zertifikate ohne Kompromisse hinsichtlich Sicherheit und Authentifizierung zu automatisieren.

Abhängig von der implementierten PKI-Topologie verfügt diese Zertifizierungsstelle über mindestens eine übergeordnete Zertifizierungsstelle. In einer einstufigen Topologie kann sie eine selbstsignierte Zertifizierungsstelle sein.

Bei der Einrichtung einer Windows Server 2003 Server- oder Windows 2000 Server-Unternehmenszertifizierungsstelle muss darauf hingewiesen werden, dass Domänencontroller in einer Active Directory-Umgebung automatisch Zertifikate anfordern, sobald eine in der Gesamtstruktur eine Unternehmenszertifizierungsstelle verfügbar ist.

Das Verhalten der automatischen Zertifikatanforderung hängt davon ab, ob auf den Computern Windows 2000- oder Windows Server 2003-Domänencontroller ausgeführt werden. Windows 2000-Domänencontroller fordern sofort Zertifikate an, sobald der Registrierungsdienst verfügbar ist. Ein Windows Server 2003-Domänencontroller fordert Zertifikate demgegenüber gemäß der Konfiguration der automatischen Registrierung in den Gruppenrichtlinieneinstellungen an. Computer mit Windows Server 2003-Domänencontroller und Computer unter Windows XP fordern Zertifikate gemäß der Konfiguration des Gruppenrichtlinienobjekts (Group Policy Object, GPO) an. Sie müssen die Verarbeitung von Anforderungen mithilfe der entsprechenden Domänengruppenrichtlinie manuell aktivieren. Beachten Sie dass, Domänencontroller über eigene GPO-Einstellungen verfügen, die sich von den anderen Computern in der Domäne unterscheiden. Führen Sie für Windows 2000-Domänencontroller die folgenden Schritte durch, um im folgenden GPO-Pfad ein Anforderungsobjekt zu erstellen und so eine Einstellung für die automatische Anforderung hinzuzufügen.

Weitere Informationen zum Konfigurieren der automatischen Registrierung für Windows Server 2003-Domänencontroller finden Sie unter Certificate Autoenrollment in Windows XP (englischsprachig) auf der Microsoft-Website.

Installationsvoraussetzungen für Unternehmenszertifizierungsstellen

Zum Installieren und Konfigurieren der Online-Unternehmenszertifizierungsstelle sind die folgenden Elemente erforderlich:

Darüber hinaus müssen die folgenden Aufgaben erledigt worden sein:

Es besteht die Möglichkeit, eine Zertifizierungsstelle auf einem Server mit mehreren Diensten oder einem Domänencontroller zu installieren. Dies wird aus Sicherheitsgründen jedoch nicht empfohlen. Eine Zertifizierungsstelle zeichnet sich durch hohe Sicherheitsanforderungen aus. Zugriff und Verwaltung sollte daher als eigenständige Ressource erfolgen.

Vorbereiten der Active Directory-Umgebung

Sie können eine Windows Server 2003-Unternehmenszertifizierungsstelle in einer Windows 2000-Umgebung einsetzen, wenn auf allen Domänencontrollern in Active Directory Windows 2000 SP3 oder höher ausgeführt wird. Windows 2000 SP3-Domänencontroller bilden die mindestens erforderliche Version, die die Schemaaktualisierung für Version 2-Vorlagen unterstützt (siehe Beschreibung im vorangegangenen Kapitel).

Die Schemaaktualisierung, die nicht zu einer vollständigen Replikation in einer Windows Server 2003-Domänenumgebung führt, ist erforderlich, um zusätzliche Vorlageninformationen, Schlüsselarchivierungsinformationen, Kreuzzertifikatobjekte und Objektbezeichnerobjekte (OID-Objekte) im Verzeichnis aufzunehmen.

Es wird davon ausgegangen, dass die Schemaaktualisierung Bestandteil des Änderungs- und Verwaltungsprozesses für die Organisation ist, da sie sich auf die gesamte Produktionsumgebung auswirken kann.

So aktualisieren Sie das Schema:

Damit die Domäne von den Windows Server 2003-Schemaerweiterungen profitieren kann, müssen Sie in jeder Domäne der Gesamtstruktur die folgenden Schritte durchführen.

Abhängig vom Replikationszeitplan dauert die Übernahme der Schemaänderungen auf allen Domänencontrollern in der Gesamtstruktur unterschiedlich lang.

Domänenmitgliedschaft

Eine Unternehmenszertifizierungsstelle kann alle Benutzer oder Computer in der Gesamtstruktur registrieren. Informationen darüber, wie die Zertifizierungsstelle Zertifikate für Benutzer und Computer ausstellen kann, die Mitglied anderer Domänen als der Domäne sind, in der die Zertifizierungsstelle installiert ist, finden Sie in den Windows Server 2003-Hilfedateien bzw. den folgenden Artikeln in der Microsoft Knowledge Base:

Wenn das Active Directory-Verzeichnis der Organisation aus mehreren Domänen besteht, müssen Sie einen Plan erarbeiten, wo die Unternehmenszertifizierungsstellen installiert werden sollen. Dabei gibt es drei verschiedene Ansätze. Sie müssen diese Möglichkeiten abhängig von den Anforderungen und vom Active Directory-Entwurf bewerten. Es gibt die folgenden Möglichkeiten:

Wenn die Unternehmenszertifizierungsstellen als Mitglieder der Stammdomäne der Gesamtstruktur ausgeführt werden, ist eine Trennung und logische Gruppierung sichergestellt. Dies kann aber für die Administratorengruppe des Gesamtstrukturstamms aufgrund von Sicherheitserwägungen nicht akzeptabel sein. Alle Möglichkeiten sind zulässig, müssen aber abhängig von der jeweiligen Umgebung sorgfältig abgewägt werden.

Abrufen von Zertifikat und Sperrliste von "CorporateRootCA" und "IntermediateCA1"

Hinweis: Bei der Implementierung einer einstufigen Topologie treffen die Schritte in diesem Abschnitt nicht für die Umgebung zu.

Während der Zertifikatüberprüfung werden Zertifikat und Sperrliste für alle Knoten in der PKI-Hierarchie benötigt.

Da alle übergeordneten Zertifizierungsstellen einer ausstellenden Unternehmenszertifizierungsstelle u. U. ohne Netzwerkverbindung ausgeführt werden (wie in diesem Beispielszenario), können die CA-Zertifikate und die neuesten Sperrlisten bei Bedarf nicht über das Netzwerk abgerufen werden. Daher müssen die CA-Zertifikate und die aktuellsten Sperrlisten aller übergeordneten Zertifizierungsstellen bereitstehen, bevor CorporateEnt1CA eingerichtet werden kann.

Wenn das Zertifikat von CorporateRootCA auf der Diskette Transfer-RootCA nicht vorhanden ist, müssen Sie die in Abrufen von Zertifikat und Sperrliste von "CorporateRootCA" weiter oben in diesem Dokument beschriebenen Schritte durchführen.

Sie können Zertifikat und Sperrliste zur Veranschaulichung über den Webregistrierungssupport der Zertifizierungsstelle von IntermediateCA1 abrufen. Internetinformationsdienste wird zum Abrufen von CA-Zertifikat und Sperrliste der Stammzertifizierungsstelle nicht benötigt, da sie aus dem Pfad %systemroot%\system32\certsrv\certEnroll\ des lokalen Systems kopiert werden können. Führen Sie die folgenden Schritte durch, um CA-Zertifikat und Sperrliste über die Webseiten abzurufen:

Verteilen eines Stamm-Zertifizierungsstellenzertifikats mit Gruppenrichtlinien

Hinweis: Bei der Implementierung einer einstufigen Topologie treffen die Schritte in diesem Abschnitt nicht für die Umgebung zu, weil eine Unternehmenszertifizierungsstelle, die als Stammzertifizierungsstelle konfiguriert ist, Zertifikate automatisch in Active Directory veröffentlicht.

Bei der Implementierung einer einstufigen Topologie treffen die Schritte in diesem Abschnitt nicht zu, weil eine Unternehmenszertifizierungsstelle, die als Stammzertifizierungsstelle konfiguriert ist, Zertifikate automatisch in Active Directory veröffentlicht.

Die Überprüfung der Zertifikate setzt die Verfügbarkeit und eine explizite Vertrauensstellung des Stammzertifizierungsstellenzertifikats voraus, von dem die Zertifikate im Zertifikatvertrauenspfad ausgestellt wurden. Das Stammzertifizierungsstellenzertifikat stellt den Ausgangspunkt für Vertrauensstellungen dar, von dem die PKI-Hierarchien abgeleitet werden.

Die einfachste Möglichkeit, den Clients das Stammzertifizierungsstellenzertifikat bereitzustellen, bilden Gruppenrichtlinien. Die Vertrauensstellung von Stammzertifizierungsstellen sollte soweit wie möglich über Gruppenrichtlinien verwaltet und gesteuert werden. Wenn ein Stammzertifizierungsstellenzertifikat zum Container der vertrauenswürdigen Stammzertifizierungsstelle hinzugefügt wurde, der Bestandteil der Domänensicherheitseinstellungen ist, erhalten Clients, die Mitglied der Domäne sind, das Stammzertifikat automatisch.

Achtung: Sie dürfen Zertifikate von untergeordneten Zertifizierungsstellen (oder Zwischenzertifizierungsstellen) nicht über die vertrauenswürdigen Stammzertifizierungsstellen in Gruppenrichtlinien oder einer Unternehmensvertrauensstellung veröffentlichen. Wenn ein untergeordnetes CA-Zertifikat Bestandteil dieser Zertifikatliste ist, die mit Gruppenrichtlinien veröffentlicht werden, stellt ein Windows-Client die Zertifikatkette nicht richtig.

Der Sicherheitsteil einer Domänengruppenrichtlinieneinstellung verteilt die Liste der vertrauenswürdigen Stammzertifikate an alle Computer, die in Active Directory enthalten und Mitglied einer Domäne sind. Da das Stammzertifikat Bestandteil der Computerrichtlinie wird, übernehmen alle Domänenbenutzer die Vertrauensstellung des Stammzertifikats von den Computern, an denen sie sich anmelden.

Hinweis

Führen Sie die folgenden Schritte durch, um das Stammzertifizierungsstellenzertifikat von CorporateRootCA über Gruppenrichtlinien auf allen Computern in der Domäne zur Liste der vertrauenswürdigen Stammzertifizierungsstellenzertifikate hinzuzufügen.

Auf der Seite Eigenschaften von Vertrauenswürdige Stammzertifizierungsstellen können Sie weitere Eigenschaften von PKI-Vertrauensstellungen konfigurieren. Klicken Sie dazu mit der rechten Maustaste auf Vertrauenswürdige Stammzertifizierungsstellen, und klicken Sie dann auf Eigenschaften.

Wenn Sie die Standardoption Stammzertifizierungsstellen von Drittanbietern und Organisationen deaktivieren, kann es beim Zugriff auf Anwendungen wie SSL-gesicherte Websites im Internet usw. zu unerwünschten Auswirkungen kommen.

Wenn nur Stammzertifikaten des Unternehmens vertraut wird, sind nur CA-Zertifikate, die in der Konfigurationspartition von Active Directory oder über Gruppenrichtlinien im Container Domänenname\Konfiguration\Services\Public Key Services\Certification Authorities vertrauenswürdig.

Sie können die Zertifikate im MMC-Snap-In Active Directory-Standorte und -Dienste überprüfen. Sie müssen den Dienstknoten einblenden, damit der Container Services angezeigt wird.

Importieren der Zertifikate und Sperrlisten der übergeordneten Zertifizierungsstelle in Active Directory

Im folgenden Abschnitt werden die Schritte zum Veröffentlichen der CA-Zertifikate und Sperrlisten von Offline-Zertifizierungsstellen (CorporateRootCA, IntermediateCA1 und CorporateSub2CA) in Active Directory beschrieben.

Wichtig: Verwenden Sie die Informationen in diesem Abschnitt nicht, wenn Sie eine einstufige Zertifizierungsstelle implementieren, weil eine einstufige Unternehmensstammzertifizierungsstelle das Stammzertifikat automatisch in Active Directory veröffentlicht.

Sie müssen Offline-Zertifizierungsstellenzertifikate und die zugehörigen Sperrlisten importieren. Dieser Importvorgang für die Veröffentlichung von CA-Zertifikaten muss bei jeder Erneuerung des Zertifikats der Offline-Zertifizierungsstelle wiederholt werden.

Außerdem muss die Sperrliste entsprechend der CRL-Veröffentlichungsstrategie importiert werden. Bei jeder Veröffentlichung einer neuen Sperrliste durch die übergeordnete Zertifizierungsstelle müssen Sie die Veröffentlichung wiederholen. Zur Vorbereitung der Umgebung auf die Installation der Unternehmenszertifizierungsstelle müssen Sie die übergeordneten CA-Zertifikate und Sperrlisten in Active Directory registrieren. Entsprechende Informationen finden Sie im folgenden Abschnitt.

Abrufen des sicheren Namens und des DNS-Namens der Zertifizierungsstelle

Die Konfigurationsinformationen, die in Windows Server 2003 Bestandteil der Sperrliste sind, unterscheiden sich von den Konfigurationsinformationen, die in den Versionen der Windows 2000-Familie enthalten waren. Eine Sperrliste, die von einer Windows 2000-Zertifizierungsstelle veröffentlicht wurde, enthält keine Informationen über den Ort der Veröffentlichung der Sperrliste. (Weitere Informationen finden Sie in diesem Dokument unter Überprüfen der veröffentlichten Sperrliste. Sie müssen beim Import in Active Directory jedoch wissen, wo die Sperrliste gespeichert werden soll.

Eine Windows Server 2003-Zertifizierungsstelle speichert diese Information im optionalen Attribut Veröffentlichte Sperrlistenstandorte einer Sperrliste, falls die entsprechende CRL-Eigenschaft eingestellt wurde. Wenn Sie einen CRL-Importvorgang auf einem Computer mit einem Windows 2000-Betriebssystem durchführen, müssen Sie den CRL-Veröffentlichungsstandort manuell angeben.

Geben Sie an einer Eingabeaufforderung den folgenden Befehl ein, um den Computernamen und den sicheren Namen der Zertifizierungsstelle anzuzeigen, und drücken Sie anschließend die EINGABETASTE.

certutil -cainfo

Sie können diesen Befehl auch auf einer Windows 2000-Zertifizierungsstelle verwenden, die in Active Directory veröffentlicht werden soll. Sie müssen sich dabei unbedingt den sicheren Kurznamen der Zertifizierungsstelle (DS-Name) und den DNS-Namen aller Windows 2000-Zertifizierungsstellen notieren. Der Befehl erzeugt eine ähnliche Ausgabe wie die folgende (fettgedruckte Elemente sind Platzhalter):

Exit module count: 1
CA name: IntermediateCA1
Sanitized CA short name (DS name): IntermediateCA1
CA type: 4 -- Stand-alone Subordinate CA
    ENUM_STANDALONE_SUBCA -- 4
CA cert count: 1
KRA cert count: 0
KRA cert used count: 0
CA cert[0]: 3 -- Valid
CA cert version[0]: 0 -- V0.0
CA cert verify status[0]: 0
CRL[0]: 3 -- Valid
CRL Publish Status[0]: 5
    CPF_BASE -- 1
    CPF_COMPLETE -- 4
Delta CRL Publish Status[0]: 0xe (14) 
    CPF_DELTA -- 2
    CPF_COMPLETE -- 4
    CPF_SHADOW -- 8
DNS Name: connoam-ca-00
Advanced Server: 1
CertUtil: -CAInfo command completed successfully.

Wenn der in der Sperrliste angegebene CRL-Pfad und der Pfad, in dem die Sperrliste physikalische gespeichert ist, nicht übereinstimmen, kann es bei der Überprüfung der Sperrliste durch einen Client zu einem IDP-Überschneidungsfehler (Issuing Distribution Point, ausstellender Verteilungspunkt) kommen.

Importieren der CA-Zertifikate und Sperrlisten von "CorporateRootCA" und "CorporateSubxCA"

Um die Installation fortzusetzen, müssen Sie die CA-Zertifikate und Sperrlisten von übergeordneten Offline-Zertifizierungsstellen in Active Directory importieren. Dieser Vorgang wird üblicherweise beim Einrichten einer CA-Umgebung durchgeführt. Die CRL-Veröffentlichung und -Verteilung mit Active Directory ist für eine erfolgreiche PKI in der Organisation von entscheidender Bedeutung. Der direkte Import von Stammzertifizierungsstellenzertifikaten in Active Directory ist der Verteilung von Stammzertifizierungsstellenzertifikaten über Gruppenrichtlinien zu bevorzugen, da diese Methode die Vertrauensstellung der Stammzertifizierungsstelle in der ganzen Gesamtstruktur und nicht nur in einzelnen Domänen sicherstellt.

CA-Zertifikat und Sperrliste werden vom Dienstprogramm Certutil.exe in Active Directory geschrieben. Certutil.exe ersetzt das Dienstprogramm Dsstore.exe, das im Windows 2000 Resource Kit zur Verfügung steht. Weitere Informationen finden Sie unter SO WIRD'S GEMACHT: Mithilfe von "Directory Services Store" in Windows 2000 eine Nicht-Windows 2000-Zertifizierungsstelle zur PKI hinzufügen in der Microsoft Knowledge Base und Das Dsstore Tool funktioniert möglicherweise nicht, wenn sich das NetBIOS Name und der Domäne-DNS-name unterscheiden (maschinelle Übersetzung) in der Microsoft Knowledge Base.

Vorsicht: Importieren Sie auf keinen Fall CA-Zertifikate und Sperrlisten mit dem im Windows 2000 Resource Kit enthaltenen Dienstprogramm Dsstore.exe in eine Windows Server 2003-Umgebung.

Führen Sie die folgenden Schritte durch, um die CA-Zertifikate und Sperrlisten von übergeordneten Offline-Zertifizierungsstellen in Active Directory zu importieren:

: Stammzertifzierungsstellen-Zertifikate
: 
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
: 
: Zertifikate der untergeordneten CA
: 
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
: 
: CRLs der Stammzertifzierungsstelle
: Da es sich um .NET CA CRLS handelt, bei denen die Veröffentlichungspunkte 
: Teil der CRL sind, ist dieser Punkt optional 
: 
: |-- Veröffentlichungspunkt ---|
: 
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
: 
: CRLs der untergeordneten CA
: 
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Hinweis: Der Parameter -f ist erforderlich, weil die zum Speichern der Zertifikate und Sperrlisten erforderliche Containerstruktur u. U. nicht vorhanden ist. Der Parameter -f ist ´nicht erforderlich, wenn die Containerstruktur bereits vorhanden ist.

Die Bereitstellung der Stammzertifizierungsstellenzertifikate über Gruppenrichtlinien oder Active Directory ist nicht die einzige Möglichkeit, um Clients die Zertifikate von vertrauenswürdigen Stammzertifizierungsstellenzertifikaten zur Verfügung zu stellen. Sie können die Stammzertifizierungsstellenzertifikate auch mithilfe der folgenden Methoden bereitstellen:

Festlegen der entsprechenden Zugriffsberechtigungen für Zertifikate und Sperrlisten

Der CA-Administrator muss sicherstellen, dass alle Clients in der PKI auf die Sperrlisten-Verteilungspunkte und das CA-Zertifikat zugreifen können.

Bei HTTP-URLs sollte Internetinformationsdienste (IIS) eingerichtet und für den anonymen Zugriff auf die URLs konfiguriert werden, die in ausgestellten Zertifikaten als Sperrlisten-Verteilungspunkte angegeben sind. Die Clients können dann unabhängig vom primären Authentifizierungsmechanismus die Sperrliste abrufen.

Bei URLs, die auf ein CRL-Objekt in Active Directory verweisen, verfügt die Gruppe Jeder standardmäßig über Lesezugriff. Damit Clients, die keine Active Directory-Mitglieder sind, auf CRL-Objekte in Active Directory zugreifen können, müssen Sie die Gruppe Jeder Leseberechtigung zur Domänenobjekt-ACL hinzufügen. Eine restriktivere Methode, mit der Sie den anonymen Zugriff konfigurieren können, besteht darin, das vordefinierte Konto Jeder durch das vordefinierte anonyme Konto zu ersetzen.

Weitere Informationen zum Hinzufügen von Leseberechtigungen für Clients außerhalb der Gesamtstruktur finden Sie auf den folgenden Microsoft-Websites:

Veröffentlichen der CA-Zertifikate und Sperrlisten von "CorporateRootCA" und "CorporateSub1CA"

Zum Veröffentlichen der Sperrlisten über HTTP ist ein Webserver wie IIS erforderlich. Führen Sie die folgenden Schritte durch, um IIS so einzurichten, dass der CRL-Veröffentlichungspunkt über HTTP bereitgestellt wird:

Hinweis: Die Dateinamen, die über HTTP veröffentlicht werden, müssen exakt mit den Namen von CA-Zertifikat und Sperrlisten-Verteilungspunkt übereinstimmen, die in der CA-Konfiguration definiert sind. Wenn die Dateinamen nicht übereinstimmen, können die Clients die Sperrliste nicht über den als Sperrlisten-Verteilungspunkt angegebenen URL abrufen.

Überprüfen der Veröffentlichung von Zertifikaten und Sperrlisten in Active Directory durch den Domänencontroller

Überprüfen Sie nach dem Import der CA-Zertifikate und Sperrlisten in Active Directory, ob die Daten am richtigen Speicherort veröffentlicht werden.

Hinweis: In einer verteilten Umgebung kommt es zu einer Verzögerung, bevor ein Domänencontroller die Zertifikate und Sperrlisten über die Active Directory-Replikation erhalten hat. Die Verzögerung hängt von der jeweiligen Konfiguration der Active Directory-Umgebung ab.

Sie können im MMC-Snap-In Active Directory-Standorte und -Dienste überprüfen, ob die CA-Zertifikate und Sperrlisten am richtigen Speicherort veröffentlicht wurden.

Wenn im AIA- oder CRL-Container nicht die richtigen Objekte vorhanden sind, müssen Sie die Objekte u. U. wie oben beschrieben manuell neu veröffentlichen.

Klicken Sie zum Löschen von abgelaufenen, gesperrten oder nicht mehr benötigten Zertifikaten oder Sperrlisten im MMC-Snap-In Active Directory-Standorte und -Dienste auf das Zertifikat bzw. die Sperrliste, und drücken Sie ENTF. Bedenken Sie, dass Clients CA-Zertifikate zum Überprüfen von Endeinheitenzertifikaten benötigen. Zum Überprüfen einer Zertifikatkette ist u. U. auch ein gesperrtes oder abgelaufenes CA-Zertifikat erforderlich!

Überprüfen des Imports von CA-Zertifikat und Sperrliste in Active Directory

Überprüfen Sie das Zertifikat von IntermediateCA1, um sicherzustellen, dass die richtigen CRL- und AIA-Informationen in Active Directory veröffentlicht wurden. Wenn Clients eine Sperrliste nicht vom Sperrlisten-Verteilungspunkt abrufen oder ein bestimmtes CA-Zertifikat nicht aus Active Directory downloaden können, generieren die Clientanwendungen beim Überprüfen des Zertifikatstatus einen Fehler.

Hinweis: Wenn der Überprüfungsvorgang in diesem Abschnitt nicht funktioniert, müssen Sie dir Fehlerursache untersuchen. Wenn der Ort der Veröffentlichung in Active Directory nicht richtig ist, müssen Sie den Ort mithilfe der Schritte im Abschnitt Veröffentlichen der CA-Zertifikate und Sperrlisten von "CorporateRootCA" und "CorporateSub1CA" korrigieren.

So überprüfen den ordnungsgemäßen Import von CA-Zertifikat und Sperrliste in Active Directory:

1.	Melden Sie sich an einem Computer an, der in Active Directory der Organisation Mitglied ist. Sie können sich mit dem Konto eines Domänenbenutzers anmelden, da jeder Benutzer über Leseberechtigung für CA-Zertifikat und Sperrliste in Active Directory verfügen muss.
2.	Legen Sie die Diskette Transfer-IntermediateCA in das Diskettenlaufwerk ein.
3.	Geben Sie folgenden Befehl an einer Eingabeaufforderung ein, und klicken Sie auf Abrufen: certutil.exe -url a:\IntermediateCA1.cer Der Befehl certutil.exe -url funktioniert für jedes X.509V3-Zertifikat. Sie können mit diesem Befehl auch Benutzerzertifikate überprüfen: Mit dem Dienstprogramm Certutil.exe können Sie die CRL- und AIA-Verteilungspunkte nur für DER-codierte (Distinguished Encoding Rules) Zertifikatdateien (CER-Dateien) überprüfen. Wenn Sie feststellen, dass der Sperrlisten-Verteilungspunkt falsch konfiguriert ist, müssen Sie das Problem in der CA-Konfiguration beheben, zu der die Sperrliste gehört. Der Sperrlisten-Verteilungspunkt ist in jedem ausgestellten Zertifikat als Attribut gespeichert. Eine falsche Konfiguration der Sperrliste kann sich auch auf Zertifikate auswirken, die bereits registriert wurden. Nach dem Klicken auf Abrufen führt Windows basierend auf der angegebenen Zertifikatdatei einen CRL- oder AIA-Download durch. Der Zertifikatname wird in Zertifikatantragsteller angezeigt. Windows listet die Sperrlisten-Verteilungspunkte des Zertifikats, die in der Sperrlisten-Verteilungspunkterweiterung des Zertifikats angegeben sind, auf und zeigt den Überprüfungsstatus an. Die folgende Abbildung zeigt ein Beispiel für eine erfolgreiche Überprüfung. Abbildung 8: URL-Abrufprogramm Bild maximieren Wenn die CRL-Überprüfung nicht funktioniert, sind die Sperrlisten-Verteilungspunkterweiterungen u. U. ungültig, oder für die Speicherorte der Sperrlisten wurden Berechtigungen festgelegt, die keinen Abruf des Objekts durch den aktuellen Benutzer zulassen.
4.	Klicken Sie im Dialogfeld Abrufen auf Zertifikate (vom AIA) und dann auf Abrufen. Da für das Stammzertifizierungsstellenzertifikat in diesem Szenario keine Sperrliste definiert ist, wird die CRL-Statusmeldung "Keine Sperrliste" angezeigt. Der Status einer fehlenden Sperrliste ist in diesem Beispiel zu erwarten, weil in der Datei CAPolicy.inf der Stammzertifizierungsstelle kein Sperrlisten-Verteilungspunkt angegeben wurde.

Vorlagenaktualisierung von Windows 2000

Bei einer Aktualisierung von Windows 2000 auf ein Mitglied der Windows Server 2003-Familie müssen Sie die Eigenschaften und Sicherheitseinstellungen vorhandener Version 1-Vorlagen aktualisieren.

Öffnen Sie für die Aktualisierung auf eine Windows Server 2003, Enterprise Edition-Zertifizierungsstellenumgebung das MMC-Snap-In Zertifikatvorlagen, das in Windows Server 2003, Enterprise Edition enthalten ist, damit die Vorlagenobjekte installiert und aktualisiert werden können. Das Snap-In erkennt die Verfügbarkeit von Vorlagen einer früheren Windows 2000-Zertifizierungsstelleninstallation und aktualisiert die Vorlagen automatisch.

Bei der Aktualisierung werden auch die für die Vorlagenverwaltung erforderlichen Berechtigungen aktualisiert. In Windows 2000 müssen Sie Mitglied der Gruppe Organisations-Admins sowie der Gruppe Domänen-Admins der Stammdomäne sein, um diese Operation durchzuführen. Weitere Informationen zu Zertifikatvorlagen finden Sie in Implementing and Administering Certificate Templates in Windows Server 2003 (englischsprachig) auf der Microsoft TechNet-Website

Vorbereiten der Datei "CAPolicy.inf" für die ausstellende Zertifizierungsstelle

Wenn Sie eine Anwendungs- oder Ausstellungsrichtlinie auf der Ebene anwenden, auf der Zertifikate für End-Einheiten ausgestellt werden, können Sie Richtlinien präzise kontrollieren. Wenn in der PKI-Hierarchie mehr als eine ausstellende Zertifizierungsstelle vorhanden ist, können auf die einzelnen Zertifizierungsstellen unterschiedliche Richtlinien angewendet werden, um verschiedene Zertifikattypen auszustellen. Richtlinien können jedoch auch auf der Ebene von übergeordneten Zertifizierungsstellen anwendet werden. In den meisten Bereitstellungen werden Richtlinien normalerweise auf der Ebene von Zwischenzertifizierungsstellen angewendet und nicht auf der Ebene von untergeordneten Knoten. Wenn Sie Richtlinien auf der Ebene von übergeordneten Zertifizierungsstellen anwenden, werden die Richtlinien von allen untergeordneten Zertifizierungsstellen übernommen. Dies kann sich eventuell auf den Entwurf der CA-Topologie auswirken.

Ein Beispiel für eine Datei CAPolicy.inf mit einer Ausstellungsrichtlinie finden Sie in CAPolicy.inf-Beispieldatei für "IntermediateCA1" weiter unten in diesem Dokument.

Installieren der ausstellenden Online-Unternehmenszertifizierungsstelle

Bei der Aktualisierung einer Windows 2000-Unternehmenszertifizierungsstelle auf eine Windows Server 2003-Zertifizierungsstelle müssen Sie sich am Computer mit einem Konto anmelden, das Mitglied der Stammdomänenadministratorengruppe und der Organisationsadministratorengruppe ist.

Bei einer Neuinstallation der ersten Windows Server 2003, Enterprise Edition-Zertifizierungsstelle in einer neuen Windows Server 2003-Gesamtstruktur muss das Installationskonto Mitglied der Gruppe Organisations-Admins und der Gruppe Domänen-Admins der Stammdomäne sein. Nach der Installation der ersten Zertifizierungsstelle sind keine Berechtigungen als Domänen-Admin der Stammdomäne mehr erforderlich.

Die Installation einer Online-Unternehmenszertifizierungsstelle unterscheidet sich von der Installation für die übergeordneten Offline-Zertifizierungsstellen. Führen Sie die folgenden Schritte aus, um CorporateEnt1CA zu installieren:

Verarbeiten der Zertifikatanforderung mit der übergeordneten Offline-Zertifizierungsstelle ("IntermediateCA1") über Webregistrierungssupport

Die nachstehenden Verfahren sollen als Beispiel gelten und stellen nicht unbedingt die optimale Methode im Hinblick auf die Sicherheit dar. Diese Informationen finden Sie auch im Artikel "HOW TO: Get a Certificate Signed by Off-Network Root Authority" (englischsprachig) in der Microsoft Knowledge Base.

Sie benötigen IIS nur dann für eine CA, wenn Clientunterstützung für die Registrierung für Clients erforderlich ist, auf denen ältere Betriebssysteme als Windows 2000 oder keine Windows-Betriebssysteme ausgeführt werden.

In einer dreischichtigen Topologie muss die Zertifikatanforderung der Unternehmenszertifizierungsstelle, die auf der Diskette gespeichert ist, vom IntermediateCA1-Computer ausgestellt werden. In einer zweischichtigen Topologie muss die Zertifikatanforderung von der Stammzertifizierungsstelle ausgestellt werden.

So fordern Sie ein Zertifizierungsstellenzertifikat über den Webregistrierungssupport an

Hinweis: Eine Anforderung muss mit dem gleichen Benutzerkonto und auf dem gleichen Computer abgerufen werden, mit dem bzw. von dem sie übermittelt wurde. Seitens der Webseite wird ein Browsercookie verwendet, um die ausstehende Anforderung zu identifizieren. Wenn Browsercookies nicht zugelassen werden oder wenn Sie einen anderen Computer verwenden, rufen Sie das Zertifikat über das MMC-Snap-In für Zertifizierungsstellen direkt von der CA ab. Weitere Informationen hierüber finden Sie im Abschnitt "Exportieren des Offline-Zwischenzertifikats auf der Stammzertifizierungsstelle" in diesem Dokument.

So stellen Sie eine ausstehende Anforderung mit dem MMC-Snap-In für Zertifizierungsstellen aus

So stellen Sie die ausstehende Anforderung über den Webregistrierungssupport aus

Hinweis: Es befinden sich keine sicherheitsrelevanten Daten auf der Diskette. Ein Zertifizierungsstellenzertifikat beinhaltet öffentliche Informationen, allerdings wurde der zugehörige private Schlüssel der CA in der CA (oder dem HSM) generiert. Der private Schlüssel verlässt nicht den Computer, auf dem die Zertifikatanforderung erstellt wurde.

Überprüfen des Zertifikats "EnterpriseSub1CA"

Zur Sicherstellung, dass das für den CorporateEnt1CA-Computer ausgestellte Zertifikat über die geeigneten Zertifikateigenschaften verfügt, sollten Sie das Zertifikat überprüfen. Öffnen Sie das Zertifikat, und prüfen Sie dessen Eigenschaften. Doppelklicken Sie zum Anzeigen des Zertifikats in Windows Explorer auf die Zertifikatdatei, oder verwenden Sie hierfür das MMC-Snap-In Zertifikatverwaltung. Vergewissern Sie sich, dass die Gültigkeitsdauer, die Schlüssellänge und die Zertifikatrichtlinien ordnungsgemäß angezeigt werden.

Installieren des Zertifikats auf dem "CorporateEnt1CA"-Computer

Das Installationsverfahren für das Zertifikat einer Unternehmenszertifizierungsstelle gestaltet sich ähnlich wie das Installationsverfahren für den "IntermediateCA1"-Computer.

Weitere Informationen finden Sie im Abschnitt "Installieren des Zertifikats auf "IntermediateCA1" über die Eingabeaufforderung" an späterer Stelle in diesem Dokument.

Überprüfen der Vertrauensstellungskette von "CorporateEnt1CA"

Nur mit einer gültigen Vertrauensstellungskette kann sichergestellt werden, dass die CA wie erwartet funktioniert. Wenn die Vertrauensstellungskette nicht korrekt ist oder wenn die ausstellende CA die Kette nicht erstellen und den Widerrufstatus von übergeordneten Zertifikaten nicht prüfen kann, gibt die ausstellende CA beim Start einen Fehler aus, und der Start schlägt fehl. Wenn die Überprüfung des Zertifizierungsstellenzertifikats fehlschlägt, wird die folgende Fehlermeldung angezeigt: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war (0x80092013).

Zur vorherigen Überprüfung der Vertrauensstellungskette des CorporateEnt1CA-Computers geben Sie an der Eingabeaufforderung run certutil -verifyCertificateName.crt ein und drücken dann die EINGABETASTE.

Es empfiehlt sich zudem, die CRL-Verteilungspunkte des CA-Zertifikats zu prüfen. Geben Sie hierzu an einer Eingabeaufforderung den folgenden Befehl ein, und drücken Sie die EINGABETASTE:

certutil -URL certificate-name.crt

Die Ausgabe des Skripts ist mit der in der folgenden Abbildung vergleichbar:

Abbildung 9. Überprüfte CRL-Verteilungspunkte
Bild maximieren

Zum Anzeigen der CRL doppelklicken Sie in der Spalte Url auf den URL der Zertifikatsperrliste.

Hinweis: Sie können eine CRL oder den AIA anhand des in einem Zertifikat angegebenen URLs prüfen. Wenn sowohl ein Zertifikat als auch ein URL angegeben sind, werden die CRLs und AIAs für alle im Zertifikat angegebenen URLs angefordert; darüber hinaus werden die Daten von der Position empfangen, die unter URL für Download festgelegt wurde.

Zum Zwecke der Problembehandlung müssen Sie ggf. auch die CRL auf den lokalen Computer downloaden, um diese zu prüfen. Dieses Verfahren ist für CRLs, auf die Sie unter Verwendung eines HTTP-Pfades zugreifen können, vollkommen unproblematisch, gestaltet sich jedoch schon wesentlich schwieriger bei CRLs, für die nur ein LDAP-CRL-Verteilungspunkt angegeben ist.

Sie können eine Kopie der CRL im Binärformat von einem LDAP-CRL-Verteilungspunkt downloaden, indem Sie den Befehl Certutil.exe verwenden. Geben Sie zu diesem Zweck den nachstehenden Befehl an der Eingabeaufforderung ein. Beachten Sie, dass die kursiv dargestellten Einträge durch das Ziel Ihrer CRL ersetzt werden müssen und dass Sie sich vergewissern müssen, dass nach dem Fragezeichen der richtige Filter hinzugefügt wurde.

certutil -store -split ldap:///CN=CorporateRootCA,CN=RootCA,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?Zertifikatsperrliste?base?objectClass=cRLDistributionPoint

Nach der Ausführung des Befehls steht in dem Verzeichnis, von dem aus Sie den Befehl Certutil.exe ausgeführt haben, eine neue CRL-Datei zur Verfügung. Die Datei trägt den Namen "Blob0_0.crl". Sie können die CRL-Datei im Windows-Explorer öffnen und wie jede andere CRL-Datei anzeigen.

PKI Health Tool

Zum Prüfen der CRL- und AIA-Speicherposition können Sie auch das PKI Health Tool ("Pkiview.msc") verwenden. Dieses Tool steht mit dem Windows Server 2003 Resource Kit bereit oder kann von der Microsoft Windows Deployment and Resource Kits-Website abgerufen werden.

Das PKI Health Tool wendet sich in erster Linie an CA-Administratoren, die im Unternehmen Verwaltungsaufgaben erfüllen. Mit dem Tool werden zunächst alle Zertifizierungsstellen (Certification Authorities - CAs) aufgelistet, die mit der aktuellen Gesamtstruktur zusammenhängen. Anschließend werden die Statuseigenschaften dieser CAs angezeigt.

Konfigurieren der Online-Unternehmenszertifizierungsstelle

Die Konfiguration des CorporateEnt1CA-Computers ist mit der Konfiguration der übergeordneten untergeordneten CA vergleichbar, und diese Konfiguration kann im Handumdrehen mit einem Stapelverarbeitungsskript erstellt werden. Der Unterschied zwischen der Konfiguration der übergeordneten CA und der Konfiguration des CorporateEnt1CA-Computers besteht in der Gültigkeitsdauer der ausgestellten Zertifikate - diese werden von den Vorlagen der Unternehmens-CA und nicht von der Registrierung gesteuert. Darüber hinaus sind für die Unternehmens-CA Deltasperrlisten aktiviert. Die Veröffentlichung von Deltasperrlisten ist unter Windows Server 2003 standardmäßig aktiviert. So konfigurieren Sie die Unternehmenszertifizierungsstelle

Wichtig: Wenn Sie das Skript zum Konfigurieren der Unternehmenszertifizierungsstelle einmal näher in Augenschein nehmen, stellen Sie ggf. fest, dass sich die Eigenschaft LDAP CRL publication von den Eigenschaften der Offline-CAs unterscheidet. Der Grund hierfür ist, dass eine Onlinezertifizierungsstelle über die Fähigkeit verfügt, das CA-Zertifikat und die CRL automatisch in Active Directory zu veröffentlichen. Daher empfiehlt es sich, der CA das Aktualisieren der Informationen zu gestatten, die am CRL- und AIA-Verteilungspunkt gespeichert sind. Bei einer Offline-CA kann diese Einstellung nicht verwendet werden, da diese über das Netzwerk nicht auf einen Domänencontroller zugreifen kann. Aus diesem Grund sind weder die CRL- noch die AIA-CRL-Verteilungspunkte, die für Offline-CAs angegeben sind, für eine Veröffentlichung konfiguriert.

Überprüfen der Konfiguration von "EnterpriseSubCA"

Mit den Verfahren in den nächsten Abschnitten können Sie sicherstellen, dass die Zertifizierungsstelle ordnungsgemäß konfiguriert ist und in die Produktionsumgebung übernommen werden kann. Es empfiehlt sich, die in den vorherigen Abschnitten dieses Dokuments aufgeführten Überprüfungsschritte zu verwenden:

Eine Unternehmenszertifizierungsstelle veröffentlicht das CA-Zertifikat und die CRL automatisch in Active Directory. Aus diesem Grund sollte Sie auch die Verfügbarkeit der CRL in Active Directory überprüfen. Es empfiehlt sich, hierzu den Befehl certutil -URL oder das PKI Health Tool zu verwenden, das im vorherigen Abschnitt besprochen wurde.

Hinweis: Die Ausgabebeispiele, die in den vorherigen Abschnitten dieses Dokuments erwähnt werden, sind nicht die gleichen wie die der IntermediateCA1-Konfiguration. Überprüfen Sie die geeigneten Parameter nach Maßgabe der "EnterpriseSubxCA"-Konfiguration.

Zum Seitenanfang

Verwaltung der Zertifizierungsstelle

Verwaltung und Überwachung einer CA stellen nach der Einrichtung der CA-Umgebung eine permanente Aufgabe dar.

Einige der wichtigsten Verfahren bei der Verwaltung einer CA sind im Folgenden aufgeführt:

Sie können eine CA, die mit dem Netzwerk verbunden ist, lokal verwalten, oder Sie können eine solche CA über eine Remoteverbindung verwalten; allerdings sind die Tools für die Pflege und Verwaltung der CA in erster Linie für lokale Vorgänge ausgelegt, da es sich bei der CA-Verwaltung um einen sensiblen Vorgang handelt, bei dem Sicherheit oberstes Gebot ist.

Wenn Sie das MMC-Snap-In für Zertifikatdienste für die Remoteverwaltung verwenden möchten, lesen Sie den Artikel "Users Allowed to Manage the CA Cannot Access It Remotely" in der Microsoft Knowledge Base. Diesem Artikel können Sie die geeigneten Schritte für den Remotezugriff auf die CA entnehmen.

Weitere Informationen über CA-Vorgänge und benutzerdefinierte Konfigurationen finden Sie im "Windows Server 2003 PKI Operations Guide" (englischsprachig) auf der Microsoft-Website.

Optimale Methoden für die Veröffentlichung von CRLs

Der folgende Abschnitt enthält Informationen und optimale Methoden für das Verwalten und Veröffentlichen von Zertifikatsperrlisten (Certificate Revocation Lists - CRLs).

CRL-Partitionierung

Der Administrator kann eine ausstellende CA mit einem neuen Schlüssel erneuern, um die CRL zu partitionieren. Wenn der neue Schlüssel und das neue Zertifikat generiert werden, verwendet die CA bei der Erzeugung von Sperrungsinformationen den neuen Schlüssel sowie alle noch nicht abgelaufenen vorherigen Schlüssel, die vorherigen Zertifikaten entsprechen. Daher kann eine CA ggf. mehrere Schlüssel gleichzeitig verwenden und veröffentlicht so auch mehrere CRLs, die diesen Schlüsseln entsprechen. Sie können mehrfach gültige Zertifikate, die einer CA zugeordnet sind, im MMC-Snap-In für Zertifizierungsstellen anzeigen, wenn Sie in den Eigenschaften der Zertifizierungsstelle auf die Registerkarte "Allgemein" klicken.

Sie können darüber hinaus auch den Erneuerungsstatus der CA ermitteln, wenn Sie das Zertifikat der CA prüfen. Die CA-Versionserweiterung gibt an, wie viele Male eine CA erneuert wurde und wie oft sie mit einem neuen Schlüssel erneuert wurde. Die folgende Abbildung enthält ein CA-Zertifikat, das drei Mal erneuert wurde. Beachten Sie, dass bei jeder Erneuerung ein neuer Schlüssel ausgestellt wurde; aus diesem Grund enthält das Attribut CA Version den Wert 3.3.

Abbildung 10. Erneuertes CA-Zertifikat
Bild maximieren

Nachdem eine CA mit einem neuen Schlüssel erneuert wurde, wird für das Signieren neuer Zertifikate nur noch der neue Schlüssel verwendet. Die nicht abgelaufenen vorherigen Schlüssel werden weiterhin zum Signieren von CRLs für Zertifikate verwendet, die mit den vorherigen Schlüsseln signiert wurden. Daher kann eine CA mehrere CRLs gleichzeitig veröffentlichen, für die jeweils ein anderer Schlüssel verwendet wurde. Diese Methode der CA-Erneuerung stellt ggf. die ideale Methode zur Steuerung der Größe der CRL und für eine effektive Partitionierung der CRL seitens der CA dar.

Automatische Generierung von Kreuzzertifikaten seitens Stammzertifizierungsstellen

Auf Computern, auf denen ein Produkt aus der Windows Server 2003-Produktfamilie ausgeführt wird, können Microsoft-Stammzertifizierungsstellen automatisch Kreuzzertifikate für eine Stammzertifizierungsstelle ausstellen und veröffentlichen, die erneuert wurde. Wenn eine Stammzertifizierungsstelle unter Windows Server 2003 beispielsweise mit einem neuen Schlüssel erneuert wird, erstellt die Stammzertifizierungsstelle ein Kreuzzertifikat des Zertifikats der erneuerten Stammzertifizierungsstelle, welches dem vorherigen Zertifikat der Stammzertifizierungsstelle als qualifiziert untergeordnet betrachtet wird. Diese Funktion ist wichtig, wenn Sie eine in Betrieb befindliche Stammzertifizierungsstelle verwalten, der von den Clients anderer Organisationen vertraut wird, die als Brücke für CAs dient oder über Kreuzzertifikate von anderen Organisationen verfügt.

Wenn Sie die Stammzertifizierungsstelle zwingen möchten, die Zertifikatvorlage "CrossCA" zu verwenden, geben Sie an der Eingabeaufforderung den folgenden Befehl ein, und drücken Sie die EINGABETASTE. Wenn Sie diesen Befehl nicht verwenden und wenn diese Einstellung nicht konfiguriert ist, verwendet die CA die Zertifikatvorlage "CrossCA" nicht (auch wenn sie verfügbar ist). Stattdessen wird ein Zertifikat unter Verwendung der in der Registrierung vordefinierten Erweiterungen generiert.

certutil -setreg ca\CRLFlags +CRLF_USE_CROSS_CERT_TEMPLATE

Wenn Sie die automatische Erzeugung von CA-Kreuzzertifikaten deaktivieren möchten, geben Sie an einer Eingabeaufforderung den folgenden Befehl ein, und drücken Sie die EINGABETASTE:

certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

Wenn die Stammzertifizierungsstelle gezwungen werden soll, beim Erzeugen von CA-Verschlüsselungszertifikaten bei Bedarf die Zertifikatvorlage "CAExchange" zu verwenden, geben Sie den folgenden Befehl ein. Ohne diese Flag verwendet die CA, sofern verfügbar, die Zertifikatvorlage "CAExchange" und erzeugt andernfalls ein Zertifikat ohne die Vorlage unter Verwendung von vordefinierten Erweiterungen.

certutil -setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE

Sicherung und Wiederherstellung von Zertifizierungsstellen

Die CA speichert Informationen über Zertifikate in einer Datenbank, und sie speichert auch die Protokolldateien, die an die Datenbank gebunden sind. Die CA muss in der Lage ein, auf die Zertifikate und Schlüssel zuzugreifen, die im Zertifikatspeicher des lokalen Computers oder auf einem Hardwaregerät gespeichert sind. Informationen zur Konfiguration der CA sind in der Registrierung gespeichert.

Sie können die Datenbank und die Protokolldateien nur mit dem Befehl certutil -backup speichern. Das Zertifikat der CA sowie die Schüssel können einzeln mit dem Befehl certutil -backupkey gesichert werden. Für die Archivierung der Datenbank wird der Befehl certutil -backupdb verwendet. Diese Datensicherungsverfahren eignen sich für einen Wiederherstellungsvorgang zum Reparieren einer beschädigten CA, wobei jedoch vorausgesetzt wird, dass die CA ordnungsgemäß konfiguriert ist. Allerdings werden mit keinem dieser Befehle die Informationen zur CA-Konfiguration oder zur Rollentrennung aus der Registrierung gesichert. Zum Sichern der CA einschließlich der Konfiguration verwenden Sie den Befehl ntbackup backup systemstate.

Hinweis: Bei einer Datensicherung der CA wird auch der private Schlüssel dieser CA gesichert. Der private Schlüssel ist die CA-Informationsoption mit der meisten Sicherheitsrelevanz. Wenn Sie den Befehl certutil -backupkey oder den Befehl zur Sicherung des Systemstatus verwenden, wird dieser Schlüssel Bestandteil der Sicherungsdaten. Daher sollten die Sicherungsdaten immer mit der gebotenen Sorgfalt behandelt werden. Wählen Sie einen wirklich sicheren Aufbewahrungsort, wenn der private Schlüssel der CA Teil der Datensicherung ist. Der Umgang mit Datensicherungsmedien muss in der Zertifikatrichtlinie und in der Sicherheitsrichtlinie der Organisation festgeschrieben sein.

Ein Datensicherungsverfahren arbeitet ggf. nicht immer den Erwartungen entsprechend, daher empfiehlt es sich, regelmäßig Tests der Wiederherstellungsvorgänge durchzuführen. Weitere Informationen zur Erstellung einer Datensicherung der CA finden Sie in den folgenden Artikel in der Microsoft Knowledge Base:

Reparieren des Zertifikatspeichers

Wenn Sie eine CA wiederherstellen, deren Zertifikat mithilfe eines Softwarekryptografieanbieters auf einem anderen Computer gespeichert ist, müssen Sie die CA-Konfiguration reparieren, damit die CA wieder auf das ursprüngliche CA-Zertifikat zugreifen kann. Werden die CA-Software, die Datenbank und die CA-Konfiguration wiederhergestellt, müssen Sie das CA-Zertifikat im Zertifikatspeicher des lokalen Computers installieren. Sie können auch mithilfe des folgenden Befehls einen HSM von mehreren Computern gemeinsam nutzen lassen:

certutil -addstore my CA01.Contoso.com_CARoot.crt

Nach Verwendung dieses Befehls geben Sie den folgenden Befehl ein, um den Zertifikathash zu ermitteln:

cerutil CA01.Contoso.com_CARoot.crt | findstr /c: Key Id Hash(sha1)

Bei Verwendung dieses Befehls wird der Wert von "CACertSHA-1Hash" angezeigt. Verwenden Sie die für den SHA-1-Hash stehende hexadezimale Zeichenfolge (auch als Fingerabdruck des Zertifikats bezeichnet) als Parameter für den folgenden Befehl. Beispielsweise könnten Sie folgenden Befehl eingeben:

certutil -repairstore my "ea c7 7d 7e e8 cd 84 9b e8 aa 71 6d f4 b7 e5 09 d9 b6 32 1b"

Zum Seitenanfang

Anhang A: Verzeichnisobjekte

Die verschiedenen mit der PKI zusammenhängenden Container wie CAs, Registrierungsdienste, Vorlagen, Objektkennungen (auch als OIDs bezeichnet), AIA- und CRL-Verteilungspunkte werden erstellt, wenn Sie die Gesamtstruktur zum ersten Mal mit der ersten Unternehmenszertifizierungsstelle einrichten. Zu diesem Zeitpunkt werden auch die Berechtigungen für die Objekte festgelegt.

Verzeichnisobjekte, die von einer Unternehmenszertifizierungsstelle erstellt werden

Bei der Installation einer Unternehmenszertifizierungsstelle werden die folgenden Objekte erzeugt:

Im Verlauf des Installationsverfahrens wird das CA-Zertifikat auch den folgenden vorhandenen Objekten hinzugefügt, um Vertrauensstellungen für Anmelde- und Authentifizierungszertifikate bereitzustellen:

Verzeichnisobjekte, die von der ersten Unternehmenszertifizierungsstelle in der Gesamtstruktur erstellt werden

Bei der Erstellung der ersten Unternehmenszertifizierungsstelle in der Gesamtstruktur werden in Active Directory im folgenden Container 29 Vorlagenobjekte installiert, wenn ein Produkt aus der Windows Server 2003-Produktfamilie ausgeführt wird, bzw. 24 Vorlagenobjekte, wenn Windows 2000 ausgeführt wird:

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Unter der Produktfamilie Windows Server 2003 werden dem Konfigurationscontainer einige zusätzliche Objektkennungscontainer (OID-Container) hinzugefügt. Da die Objektkennungen in V2-Vorlagen (Version 2) nicht hartcodiert sind, sind für die Arbeit mit solchen Vorlagen Objektkennungscontainer erforderlich. Nur Clients unter Windows XP oder höher können Objektkennungen in Active Directory zu Anzeigenamen auflösen.

CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=

Weitere Informationen hierüber finden Sie in Artikel 287547, "Object IDs Associated with Microsoft Cryptography" (englischsprachig) in der Microsoft Knowledge Base.

Zum Seitenanfang

Inhalt von \\Localhost\CertConfig und \\Localhost\CertEnroll

Da nach einer gewissen Zeit in den Freigaben \CertConfig und \CertEnroll mehr als eine Zertifikatdatei vorhanden ist, werden in der folgenden Tabelle die Dateinamenerweiterungen von Zertifikatdateien sowie deren Zweck erläutert. Wenn der Name der CA als Teil des Dateinamens verwendet wird, werden dem sicheren CA-Namen einige zusätzliche Escapezeichen hinzugefügt, um beliebige erweiterte ASCII-Zeichen im Dateinamen unterzubringen. Diese Escapezeichen werden im Dateinamen als "%20" angezeigt.

Tabelle 21. Zertifikatpfade und Dateinamenerweiterungen

Die Kreuzzertifikate werden automatisch generiert, wenn der Zertifikatdienst nach der Erneuerung des Zertifikats einer Stammzertifizierungsstelle mit einem neuen Schlüssel gestartet wird. Kreuzzertifikate werden nicht für untergeordnete CAs erstellt, und sie treten nicht auf, wenn ein Stammzertifikat mit dem gleichen Schlüssel erneuert wird. Wenn Sie nach der Erneuerung des Zertifikats einer Stammzertifizierungsstelle mit einem neuen Schlüssel eine Aktualisierung von Windows 2000 Server vornehmen, wird das Kreuzzertifikat beim erste Start des Zertifikatserverdienstes nach der Aktualisierung auf Windows Server 2003 generiert.

Im Folgenden finden Sie ein Beispiel für "\\Localhost\CertEnroll" nach der sauberen Installation einer Stammzertifizierungsstelle.

C:\>dir \\Localhost\certenroll
 Volume in drive \\Localhost\certenroll has no label.
 Volume Serial Number is CC0E-CACB
 Directory of \\Localhost\certenroll
06/12/2002  11:57 AM    <DIR>          .
06/12/2002  11:57 AM    <DIR>          ..
06/12/2002  11:32 AM             1,299 concorp-
ca-00_CorporateRootCA.crt
06/12/2002  11:32 AM               925 CorporateRootCA.crl
06/12/2002  11:32 AM               321 nsrev_CorporateRootCA.asp
               3 File(s)          2,545 bytes
               2 Dir(s)   4,478,095,360 bytes free

Im Folgenden finden Sie ein Beispiel für "\\Localhost\CertConfig" nach der sauberen Installation einer Stammzertifizierungsstelle.

C:\>dir \\localhost\certenroll
 Volume in drive \\localhost\certenroll has no label.
 Volume Serial Number is CC0E-CACB
 Directory of \\localhost\certenroll
06/11/2002  07:48 PM    <DIR>          .
06/11/2002  07:48 PM    <DIR>          ..
06/11/2002  05:31 PM             1,338 concorp-
ca-00_CorporateRootCA(1).crt
06/11/2002  05:31 PM             1,928 concorp-ca-00_CorporateRootCA
(0-1).crt
06/11/2002  05:31 PM             1,940 concorp-ca-00_CorporateRootCA
(1-0).crt
06/11/2002  07:48 PM             1,338 concorp-
ca-00_CorporateRootCA(2).crt
06/11/2002  11:57 AM             1,299 concorp-
ca-00_CorporateRootCA.crt
06/11/2002  05:31 PM               943 CorporateRootCA(1).crl
06/11/2002  05:32 PM               938 CorporateRootCA.crl
06/11/2002  11:57 AM               321 nsrev_CorporateRootCA.asp
               8 File(s)         10,045 bytes
               2 Dir(s)   4,481,171,456 bytes free

Im Folgenden finden Sie ein Beispiel für "\\Localhost\CertEnroll" nach zwei Schlüsselerneuerungen auf der CA.

C:\>dir \\localhost\certenroll
 Volume in drive \\localhost\certenroll has no label.
 Volume Serial Number is CC0E-CACB
 Directory of \\localhost\certenroll
06/11/2002  07:48 PM    <DIR>          .
06/11/2002  07:48 PM    <DIR>          ..
06/11/2002  05:31 PM             1,338 concorp-
ca-00_CorporateRootCA(1).crt
06/11/2002  05:31 PM             1,928 concorp-ca-00_CorporateRootCA
(0-1).crt
06/11/2002  05:31 PM             1,940 concorp-ca-00_CorporateRootCA
(1-0).crt
06/11/2002  07:48 PM             1,338 concorp-
ca-00_CorporateRootCA(2).crt
06/11/2002  11:57 AM             1,299 concorp-
ca-00_CorporateRootCA.crt
06/11/2002  05:31 PM               943 CorporateRootCA(1).crl
06/11/2002  05:32 PM               938 CorporateRootCA.crl
06/11/2002  11:57 AM               321 nsrev_CorporateRootCA.asp
               8 File(s)         10,045 bytes
               2 Dir(s)   4,481,171,456 bytes free 

Im Folgenden finden Sie ein Beispiel für "\\Localhost\CertConfig" nach zwei Schlüsselerneuerungen auf der CA.

C:\>dir \\localhost\certconfig
 Volume in drive \\localhost\certconfig has no label.
 Volume Serial Number is CC0E-CACB
 Directory of \\localhost\certconfig
06/11/2002  07:48 PM    <DIR>          .
06/11/2002  07:48 PM    <DIR>          ..
06/11/2002  11:27 AM               105 certsrv.bak
06/11/2002  11:57 AM               216 certsrv.txt
06/11/2002  05:31 PM             1,928 concorp-ca-00_CorporateRootCA
(0-1).crt
06/11/2002  05:31 PM             1,338 concorp-
ca-00_CorporateRootCA(1).crt
06/11/2002  05:31 PM             1,940 concorp-ca-00_CorporateRootCA
(1-0).crt
06/11/2002  07:48 PM             1,338 concorp-
ca-00_CorporateRootCA(2).crt
06/11/2002  11:57 AM             1,299 concorp-
ca-00_CorporateRootCA.crt
04/24/2002  10:53 AM             1,942 connoam-ca-00_CONNOAM-CA-00.req
               8 File(s)         10,106 bytes
               2 Dir(s)   4,481,171,456 bytes free

Zum Seitenanfang

Beziehung zwischen Konfigurationscontainer und Zertifikatspeicher

In der Tabelle in diesem Abschnitt wird die Beziehung zwischen den Informationen veranschaulicht, die im Konfigurationscontainer von Active Directory und im Zertifikatspeicher gespeichert sind. In der Regel werden Teile der Konfigurationsinformationen auf die Zertifikatspeicher von Clients repliziert.

In der Standardansicht des MMC-Snap-Ins für Zertifikate wird die physikalische Struktur des Zertifikatspeichers nicht angezeigt. Gehen Sie daher wie folgt vor, um die physikalische Struktur des Zertifikatspeichers anzuzeigen:

Hinweis: Alle Informationen, die im Registrierungscontainer gespeichert sind, wirken sich nur auf den lokalen Client aus. Registrierungscontainer erhalten niemals Informationen aus dem Active Directory-Konfigurationskontext. Der Container Zwischenzertifizierungsstelle - Gruppenrichtlinie wird im Zertifikatspeicher des Clients nicht verwendet.

Zertifikate, die im Active Directory-Konfigurationscontainer (Standorte und Dienste) gespeichert sind, werden auf alle Clients in der Gesamtstruktur verteilt. Zertifikate, die über die Domänensicherheit bereitgestellt werden, werden nur in der Domäne bereitgestellt. Wenn ein Zertifikat im Konfigurationscontainer und im Domänen-Gruppenrichtlinienobjekt (GPO) registriert ist, kann es ggf. zwei Mal auf dem Client auftreten. Zur Vermeidung möglicher Verwechselungen mit abgelaufenen oder ungültigen Zertifikaten müssen Sie sicherstellen, dass Zertifikate ordnungsgemäß veröffentlicht werden.

Sie können den Active Directory-Konfigurationskontext über das MMC-Snap-In Active Directory-Standorte und -Dienste anzeigen.

Tabelle 22. Zertifikatcontainer und Zertifikatspeicher

Zum Seitenanfang

Standardmäßiges CA-Zertifikat und CRL-Speicher

Während der Installation der Stammzertifizierungsstelle wird das Stammzertifikat unter den folgenden Pfaden gespeichert:

Die erste CRL wird unter den folgenden Pfaden gespeichert:

Das CA-Zertifikat einer eigenständigen CA wird unter den folgenden Pfaden gespeichert:

Die CRL der Stammzertifizierungsstelle sollte an den folgenden Positionen gespeichert werden:

Die CRL einer eigenständigen CA wird unter den folgenden Pfaden gespeichert:

Zum Seitenanfang

Zuordnen von benutzerdefinierten Objektkennungen zu Anzeigenamen

Wenn ein Zertifikat registriert wird und dieses Zertifikat über eine benutzerdefinierte Objektkennung und über Richtlinieninformationen verfügt, kann im Zweck des registrierten Zertifikats eine Objektkennung anstelle eines Anzeigenamens angezeigt werden.

Dies tritt auf, da die Vorlage, die für die Zertifikatregistrierung verwendet wird, die Objektkennung nicht in einen Anzeigenamen auflösen kann. Aus diesem Grund werden benutzerdefinierte Objektkennungen über den Container "Objektkennung" (auch als OID) bezeichnet in Active Directory Anzeigenamen zugeordnet. Die Zuordnung muss in der V2-Vorlage erfolgen, von der die Objektkennung verwendet wird. So wandeln Sie eine Objektkennung in einen Anzeigenamen um

Zum Seitenanfang

Syntax von "CAPolicy.inf"

Zweck und Syntax der Konfigurationsdatei "CAPolicy.inf" werden in der Hilfe zu Windows Server 2003 erläutert.

Wenn eine Datei mit Namen "CAPolicy.inf" vorhanden ist, setzt diese die Standardkonfiguration außer Kraft, die bei der Installation der CA oder bei der Erneuerung von deren Zertifikat verwendet wurde.

CAPolicy.inf-Beispieldatei für "CorporateRootCA"

Sie können die Beispieldatei in diesem Abschnitt für die Datei "CAPolicy.inf" der Stammzertifizierungsstelle verwenden. Vergewissern Sie sich, dass die Parameter im Abschnitt [Certsrv_Server] Ihren Anforderungen nach Maßgabe der Zertifikatverwendungserklärung (CPS) entsprechen.

Hinweis: Die im Abschnitt [Certsrv_Server] angegebenen Parameter müssen die gleiche oder eine größere Schlüssellänge bzw. die gleiche oder eine längere Gültigkeitsdauer aufweisen als die, die bei der Einrichtung der CA verwendet wurden, andernfalls wird der in CAPolicy.inf angegebene Wert ignoriert.

Die passende "CAPolicy.inf"-Datei für eine Windows 2000-Stammzertifzierungsstelle sieht so aus:

[Version]
Signature= "$Windows NT$" 
 [Certsrv_Server] 
RenewalKeyLength=4096 
RenewalValidityPeriodUnits=Years 
RenewalValidityPeriod=20 
 [CRLDistributionPoint] 
 [AuthorityInformationAccess]

Die passende "CAPolicy.inf"-Datei für eine Windows Server 2003-Stammzertifzierungsstelle sieht so aus:

[Version]
Signature= "$Windows NT$"
[Certsrv_Server] 
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
[CRLDistributionPoint] 
[AuthorityInformationAccess]

Die beiden oben dargestellten CAPolicy.inf-Dateien unterscheiden sich hinsichtlich der Parameter RenewalValidityPeriod und RenewalValidityPeriodUnits. Unter Windows Server 2003 wurde die Benennung der Parameter mit den in der Registrierdatenbank verwendeten Namen vereinheitlicht.

CAPolicy.inf-Beispieldatei für "IntermediateCA1"

Dieser Abschnitt enthält ein Beispiel für die Datei "CAPolicy.inf" der untergeordneten CA.

Die Objektkennungen und URLs werden nur als Beispiel angegeben. Sie sollten die Werte für die Objektkennungen durch die Objektkennungen ersetzen, die in Ihrer Organisation verwendet werden, und überprüfen, dass die URLs auf eine Position verweisen, auf die zugegriffen werden kann.

Die Syntax der Datei "CAPolicy.inf" ist unter Windows 2000 und Windows Server 2003 grundlegend die gleiche, mit der Ausnahme, dass der Abschnitt [CApolicy], der unter Windows 2000 gültig ist, unter Windows Server 2003 durch [PolicyStatementExtension] ersetzt wurde.

Bei einer CA unter Windows 2000 sollte die Datei "CAPolicy.inf" wie im folgenden Beispiel dargelegt aussehen. Kursiv dargestellte Element sind Platzhalter. Diese Platzhalter sollten durch Angaben ersetzt werden, die Ihrer spezifischen Situation entsprechen.

[Version] 
Signature= "$Windows NT$" [CApolicy] 
Policies = AllIssuancePolicy
Critical = FALSE
[AllIssuancePolicy] 
OID = 2.5.29.32.0

Bei einer CA unter Windows Server 2003 sollte die Datei "CAPolicy.inf" wie im folgenden Beispiel dargelegt aussehen.

[Version]
Signature= "$Windows NT$" [CApolicy] 
Policies = AllIssuancePolicy
Critical = FALSE
[AllIssuancePolicy] 
OID = 2.5.29.32.0

CAPolicy.inf-Beispieldatei für "CorporateEnt1CA"

Unter der Produktfamilie Windows 2000

[Version]
Signature= "$Windows NT$"
[CApolicy] 
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy] 
OID = 1.1.1.1.1.1.1.1.1
URL = "http://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy] 
OID = 2.2.2.2.2.2.2.2.2
URL = "http://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"

Unter der Produktfamilie Windows Server 2003

[Version] 
Signature= "$Windows NT$"
[PolicyStatementExtension] 
Policies = LegalPolicy, LimitedUsePolicy
[LegalPolicy] 
OID = 1.1.1.1.1.1.1.1.1
URL = "http://www.contoso.com/pki/Policy/USLegalPolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLegalPolicy.txt"
[LimitedUsePolicy] 
OID = 2.2.2.2.2.2.2.2.2
URL = "http://www.contoso.com/pki/Policy/USLimitedUsePolicy.asp"
URL = "ftp://ftp.contoso.com/pki/Policy/USLimitedUsePolicy.txt"

Zum Seitenanfang

Platzhaltertoken für den CRL-Verteilungspunkt

Platzhaltertoken werden verwendet, um die Konfiguration von Verteilungspunkten flexibel zu halten. Sie können Platzhaltertoken in der Datei CAPolicy.inf und im MMC-Snap-In für Zertifizierungsstellen unter CA-Erweiterungen verwenden.

Ein Platzhaltertoken besteht aus einem Prozentzeichen und einer Zahl. Dies gilt, wenn Sie Platzhaltertoken im MMC-Snap-In für Zertifikatdienste oder im Befehl certutil verwenden. Werden Platzhaltertoken in einer Stapelverarbeitungsdatei verwendet, müssen Sie bei Verwendung des Prozentzeichens (%) ggf. ein weiteres Escapezeichen einsetzen, da ein Prozentzeichen in der Windows-Shell in der Regel als Befehlszeilenparameter interpretiert wird.

Die Zuordnung von Platzhaltertoken ist in späteren Windows-Versionen als Windows 2000 Server unterschiedlich. Weitere Informationen und eine Liste der Platzhaltertoken, die auf Computern unter Windows 2000 gelten, finden Sie in Artikel 283119, "Error Message: A Replacement Token Entered Does Not Match Any Recognized Token" (englischsprachig) in der Microsoft Knowledge Base.

Sie können die folgenden Token für CRLDistributionPoint-, AuthorityInformationAccess- und CrossCertificateDistributionPointsExtension-URLs verwenden.

Tabelle 23. Platzhaltertoken für CRL-Verteilungspunkte

Beim Setup des Zertifizierungsservers werden alle %Nummer%-Sequenzen durch den geeigneten Wert ersetzt.

Zum Seitenanfang

CRL-Veröffentlichungseigenschaften

Das Flag Sperrlisten an diesem Ort veröffentlichen wird verwendet, um die Positionen zu bezeichnen, an denen die CA die physikalischen CRLs veröffentlichen (oder ablegen) soll, wenn die CRLs der CA entweder automatisch oder manuell veröffentlicht werden. Dieses Flag gibt lediglich an, wo CRLs veröffentlicht werden sollen. Es wird zudem im Befehl certutil.exe -dspublish verwendet, wenn CRLs automatisch in Active Directory veröffentlicht werden. Sowohl über das Flag Zertifikatsperrliste veröffentlichen als auch über das Flag Deltasperrlisten veröffentlichen auf der Seite Eigenschaften von gesperrten Zertifikaten kann die Veröffentlichungsaktivität aktiviert oder deaktiviert werden.

Mit dem Flag Sperrlisten an diesem Ort veröffentlichen werden die Positionen angegeben, an denen die CA versuchen soll, die CRL zu veröffentlichen. Mit diesem Flag wird der Server nicht für die Durchführung von Veröffentlichungsvorgängen konfiguriert, sondern lediglich so eingerichtet, dass die CA im Falle einer Veröffentlichung die geeigneten Positionen ermitteln kann. Beachten Sie, dass der eigentliche Veröffentlichungsvorgang von den Eigenschaften unter Gesperrte Zertifikate gesteuert wird.

Mit dem Flag In alle Sperrlisten einbeziehen wird festgelegt, dass die Active Directory-Veröffentlichungsposition in die CRL selbst aufgenommen werden soll. Diese Angabe ist für die Veröffentlichung von Offline-CRLs in Active Directory unter Verwendung des Tools Certutil.exe nützlich. Geben Sie hierzu an der Eingabeaufforderung certutil -dspublish ein, und drücken Sie die EINGABETASTE.

Das Flag In CDP-Erweiterung von ausgestellten Zertifikaten einbeziehen wird von Clients verwendet, um die Position des CRL-Verteilungspunktes der CRL zu finden. Dieses Flag sollten Sie immer angeben, es sei denn, Sie möchten die clientseitige oder anwendungsseitige Überprüfung der Sperrung von ausgestellten Zertifikaten deaktivieren.

Das Flag In Sperrlisten einbeziehen. Wird zur Suche von Deltasperrlisten verwendet wird von Clients verwendet, um festzustellen, ob eine Delta-CRL vorhanden ist und wo sich diese befindet. Diese Position kann, muss jedoch nicht unbedingt, der Position der CRL entsprechen. Die Position der Delta-CRL wird in der CRL mit der Erweiterung freshestCRL im CRL-Objekt selbst angegeben.

Möglicherweise möchten Sie aufgrund von Unterschieden bei der Replikation eine Basis-CRL unter einem LDAP-Pfad in Active Directory und eine Delta-CRL unter einem alternativen HTTP-Pfad speichern. Wenn die Delta-CRL in einem Zeitintervall ausgestellt wird, das kürzer als die Replikationskonvergenzzeit Ihrer Gesamtstruktur ist, sollte die Delta-CRL nicht in Active Directory veröffentlicht werden. In vielen Active Directory-Netzwerken dauert es möglicherweise Stunden, bis Active Directory-Objekte im gesamten Netzwerk repliziert wurden. Bei Delta-CRLs, die ggf. nur eine Gültigkeitsdauer von wenigen Stunden aufweisen, bedeutet diese Replikationslatenz häufig, dass Active Directory-Clients ein Delta-CRL-Objekt erst dann erhalten, wenn es bereits abgelaufen ist. Diese Latenz können Sie vermeiden, indem Sie die Delta-CRL unter einem HTTP-Pfad auf fehlertoleranten Webservern veröffentlichen, von dem alle Clients unmittelbar eine aktuelle Delta-CRL abrufen können.

Tabelle 24. CRL-Veröffentlichungseigenschaften

Zum Seitenanfang

AIA-Veröffentlichungseigenschaften

In der nachstehenden Tabelle werden die Veröffentlichungseigenschaften für AIA (Authority Information Access - Zugriff auf Stelleninformationen) aufgeführt.

Tabelle 25. AIA-Veröffentlichungseigenschaften

Zum Seitenanfang

Beispielskript zum Konfigurieren von "CorporateRootCA"

Mit dem Skript in diesem Abschnitt werden die wichtigsten Konfigurationsänderungen an einer CA unter Windows Server 2003 für den "CorporateRootCA"-Computer vorgenommen.

Wichtig: Da Prozentvariablen (%) in Stapelverarbeitungsdateien und an der Eingabeaufforderung unterschiedlich verarbeitet werden, müssen Sie zwei Prozentzeichen (%%) verwenden, wenn dieses Skript wie erläutert über eine Stapelverarbeitungsdatei ausgeführt werden soll. Wenn certutil über die Eingabeaufforderung und nicht über eine Stapelverarbeitungsdatei aufgerufen wird, verwenden Sie nur ein und keine zwei Prozentzeichen.

REM
REM CA configuration script for a Windows Server 2003 CA
REM
REM The naming context applies to the individual organizations Active
Directory
REM configuration
REM
SET myADnamingcontext=DC=concorp,DC=contoso,DC=com
REM
REM This variable directs to the HTTP publication location that is used
for
REM the CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organizations Active
REM Directory, no specific LDAP server name is provided.
REM Set an dedicated server-name instead
REM if a known server should provide the CRLs and AIAs
REM
SET myLDAPserver=
REM
REM Map the namespace of Active Directory
REM
certutil.exe -setreg ca\DSConfigDN
"CN=Configuration,%myADnamingcontext%"
REM
REM Configure CRL and AIA CDP
REM
REM By default, Certutil creates a registry value of type REG_SZ if a
string is
REM specified as a parameter. Some registry values are expected as
REG_MULTI_SZ. To
REM create a REG_MULTI_SZ instead of a REG_SZ, add a \n to the end of
any value that
REM becomes part of the REG_MULTI_SZ
REM
certutil -setreg CA\CRLPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:%myhttp
PKIvroot%/%%3%%8%%9.crl\n10:ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,
CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%myhttp
PKIvroot%/%%1_%%3%%4.crt\n2:ldap://%myLDAPserver%/CN=%%7,CN=AIA,
CN=Public Key Services,CN=Services,%%6%%11"
REM
REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
REM
REM Disable Delta CRL publication
REM
certutil -setreg CA\CRLDeltaPeriodUnits 0
REM
REM Set the validity period for issued certificates
REM
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Repair CA file system shares and IIS virtual roots
REM
certutil -vroot
REM
REM Republish the CRL
REM The CRL publishing may immediately not work
REM after you restart the CA server service. If this behavior
REM occurs, try the certutil –CRL command at a command
REM prompt again.
REM
certutil -CRL
REM
REM Test if CAPolicy.inf file exists
REM
IF EXIST %SYSTEMROOT%\capolicy.inf GOTO ENDCFG
ECHO Warning, no capolicy.inf file used
:ENDCFG

Mit dem folgenden Skript werden die gleichen Konfigurationsdaten wie im vorherigen Skript für die Konfiguration einer CA unter Windows 2000 übernommen. Denken Sie daran, dass Delta-CRL-Konfigurationsparameter in der Windows 2000-CA-Umgebung nicht unterstützt werden. Zum Ausführen der Befehle certutil -URL und certutil -vroot muss auf dem CA-Computer unter Windows 2000 die Version von certutil verwendet werden, die zum Lieferumfang von Windows Server 2003 gehört.

REM
REM CA configuration script for a Windows 2000 CA
REM
REM This variable directs to the HTTP publication location that is used
for
REM the CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organizations Active
REM Directory, no specific LDAP server name is provided. Set a
dedicated server
REM name instead, if a known server should provide the CRLs and AIAs.
REM
SET myLDAPserver=
REM
REM Configure CRL and AIA CDP
REM
certutil -setreg policy\FileRevocationCRLURL "\n
certutil -setreg policy\RevocationCRLURL
%myhttpPKIvroot%/%%3%%8.crl\n
certutil -setreg policy\LDAPRevocationCRLURL
ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,
CN=Services,%%6?certificateRevocationList?base?objectclass=
cRLDistributionPoint\n"
certutil -setreg policy\FileIssuercertURL  "\n
certutil -setreg policy\IssuercertURL %myhttpPKIvroot%/%%1_%%3%%4.crt"
certutil -setreg policy\LDAPIssuercertURL
ldap://%myLDAPserver%/CN=%%7,CN=AIA,CN=Public  Key
 Services,CN=Services,%%6?cACertificate?base?objectclass=
certificationAuthority
REM
REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
REM
REM Set the validity period for issued certificates
REM
certutil -setreg ca\ValidityPeriodUnits 10
certutil -setreg ca\ValidityPeriod "Years"
REM
REM Disable issuer name and issuer serial number
REM
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Repair CA files-system shares and IIS virtual roots
REM
certutil -vroot
REM
REM Publish the CRL with the updated CDP and naming information.
REM It might happen that CRL publishing fails immediately
REM after the CA server service has been restarted. If this
REM is the case, try certutil –CRL at a command prompt again.
REM
certutil -CRL

Zum Seitenanfang

Beispielskript zum Konfigurieren von "IntermediateCA"

Mit dem Skript in diesem Abschnitt werden die wichtigsten Konfigurationsänderungen an einer CA unter Windows Server 2003 für den "IntermediateCA"-Computer vorgenommen.

REM
REM CA configuration script for a Windows Server 2003 CA
REM
REM The naming context applies to the individual organizations Active
Directory
REM configuration
REM
SET myADnamingcontext=DC=concorp,DC=contoso,DC=com
REM
REM This variable directs to the HTTP publication location that is used
for
REM the CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organizations Active
REM Directory, no specific LDAP server name is provided. Set an
dedicated server
REM name instead, if a known server should provide the CRLs and AIAs.
REM
SET myLDAPserver=
REM
REM Map the namespace of Active Directory
REM
certutil.exe -setreg ca\DSConfigDN
"CN=Configuration,%myADnamingcontext%"
REM
REM Configure CRL and AIA CDP
REM
REM By default, Certutil creates a registry value of type REG_SZ if a
string is
REM specified as a parameter. Some registry values are expected as
REG_MULTI_SZ.
REM To create a REG_MULTI_SZ instead of a REG_SZ, add a \n to the end
of any value
REM that becomes part of the REG_MULTI_SZ
REM
certutil -setreg CA\CRLPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:%myhttp
PKIvroot%/%%3%%8%%9.crl\n10:ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,
CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs
"1:%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%myhttp
PKIvroot%/%%1_%%3%%4.crt\n2:ldap://%myLDAPserver%/CN=%%7,CN=AIA,
CN=Public Key Services,CN=Services,%%6%%11"
REM
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
REM Set the validity period for issued certificates
REM
certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod "Years"
REM
REM Include certificate policies in certificate request
REM
certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
REM
REM
REM Disable issuer name and issuer serial number
REM
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Repair CA files-system shares and IIS virtual roots
REM
certutil -vroot
REM
REM Republish the CRL
REM It might happen that CRL publishing fails immediately
REM after the CA server service has been restarted. If this
REM is the case, try certutil –CRL at a command prompt again.
REM
certutil -CRL

Mit dem folgenden Skript werden die gleichen Konfigurationsdaten wie im vorherigen Skript für die Konfiguration einer CA unter Windows 2000 übernommen. Denken Sie daran, dass Delta-CRL-Konfigurationsparameter in der Windows 2000-CA-Umgebung nicht unterstützt werden. Zum Ausführen der Befehle certutil -URL und certutil -vroot muss auf dem CA-Computer unter Windows 2000 die Version des Dienstprogramms certutil verwendet werden, die zum Lieferumfang von Windows Server 2003 gehört.

REM
REM CA configuration script for a Windows 2000 CA
REM
REM This variable directs to the HTTP publication location that is used
for
REM the CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organizations Active
REM Directory, no specific LDAP server name is provided. Set a
dedicated server
REM name instead if a known server should provide the CRLs and AIAs.
REM
SET myLDAPserver=
REM
REM Configure CRL and AIA CDP
REM
REM By default, certutil creates a registry value of type REG_SZ if a
string is
REM specified as a parameter. Some registry values are expected as
REG_MULTI_SZ. To
REM create a REG_MULTI_SZ value instead of a REG_SZ value, add \n to
the end of any
REM value that becomes part of REG_MULTI_SZ.
REM
certutil -setreg policy\FileRevocationCRLURL \n
certutil -setreg policy\RevocationCRLURL
%myhttpPKIvroot%/%%3%%8.crl\n
certutil -setreg policy\LDAPRevocationCRLURL
ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,
CN=Services,%%6?certificateRevocationList?base?objectclass=
cRLDistributionPoint\n"
certutil -setreg policy\FileIssuercertURL
"%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n
certutil -setreg policy\IssuercertURL %myhttpPKIvroot%/%%1_%%3%%4.crt"
certutil -setreg policy\LDAPIssuercertURL
ldap://%myLDAPserver%/CN=%%7,CN=AIA,CN=Public 
Key Services,CN=Services,%%6?cACertificate?base?objectclass=
certificationAuthority
REM
REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 30
certutil -setreg CA\CRLPeriod "Days"
REM
REM Set the validity period for issued certificates
REM
certutil -setreg ca\ValidityPeriodUnits 5
certutil -setreg ca\ValidityPeriod "Years"
REM
REM Include certificate policies in certificate request
REM
certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
REM
REM
REM Disable issuer name and issuer serial number
REM
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Repair CA files-system shares and IIS virtual roots
REM
certutil -vroot
REM
REM Republish the CRL.
REM It might happen that CRL publishing fails immediately
REM after the CA server service has been restarted. If this
REM is the case try certutil –CRL at a command prompt again.
REM
certutil -CRL

Zum Seitenanfang

Beispielskript zum Konfigurieren von "EnterpriseSubCA"

Mit dem Skript in diesem Abschnitt werden die wichtigsten Konfigurationsänderungen an einer CA unter Windows Server 2003 für den "EnterpriseCA"-Computer vorgenommen.

Wichtig: Da Prozentvariablen (%) in Stapelverarbeitungsdateien und an der Eingabeaufforderung unterschiedlich verarbeitet werden, müssen Sie zwei Prozentzeichen (%%) verwenden, wenn dieses Skript wie erläutert über eine Stapelverarbeitungsdatei ausgeführt werden soll. Wenn certutil über die Eingabeaufforderung und nicht über eine Stapelverarbeitungsdatei aufgerufen wird, verwenden Sie nur ein und keine zwei Prozentzeichen.

REM
REM CA configuration script for a Windows Server 2003 CA
REM
REM This variable directs to the HTTP publication location that is used
for
REM CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organization's Active
REM Directory, no specific LDAP server name is provided.
REM
SET myLDAPserver=
REM
REM Configure CRL and AIA CDP
REM
certutil -setreg CA\CRLPublicationURLs "65:
%WINDIR%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:%myhttp
PKIvroot%/%%3%%8%%9.crl\n79:ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,
CN=CDP,CN=Public Key Services,CN=Services,%%6%%10"
certutil -setreg CA\CACertPublicationURLs  "1:
%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt
n2:%myhttpPKIvroot%/%%1_%%3%%4.crt\n2:ldap://%myLDAPserver%/CN=%%7,
CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\"
REM
REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "Days"
REM
REM Disable issuer name and issuer serial number
REM
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Create Web virtual roots and file shares
REM
certutil.exe -vroot
REM
REM Republish the CRL
REM
certutil -CRL

Mit dem folgenden Skript werden die gleichen Konfigurationsdaten wie im vorherigen Skript für die Konfiguration einer CA unter Windows 2000 übernommen. Denken Sie daran, dass Delta-CRL-Konfigurationsparameter in der Windows 2000-CA-Umgebung nicht unterstützt werden. Zum Ausführen der Befehle certutil -URL und certutil -vroot muss auf dem CA-Computer unter Windows 2000 die Version von Certutil.exe verwendet werden, die zum Lieferumfang von Windows Server 2003 gehört.

REM
REM CA configuration script for a Windows 2000 CA
REM
REM This variable directs to the HTTP publication location that is used
for
REM the CRL and AIA publication
REM
SET myhttpPKIvroot=http://www.contoso.com/pki
REM
REM Because CRLs and CA certificates are published in the
organization's Active
REM Directory, no specific LDAP server name is provided. Set a
dedicated server
REM name instead if a known server should provide the CRLs and AIAs.
REM
SET myLDAPserver=
REM
REM Configure CRL and AIA CDP
REM
certutil -setreg policy\FileRevocationCRLURL "\n
certutil -setreg policy\RevocationCRLURL
%myhttpPKIvroot%/%%3%%8.crl\n
certutil -setreg policy\LDAPRevocationCRLURL
ldap://%myLDAPserver%/CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,
CN=Services,%%6?certificateRevocationList?base?objectclass=
cRLDistributionPoint\n"
certutil -setreg policy\FileIssuercertURL
"%WINDIR%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n
certutil -setreg policy\IssuercertURL %myhttpPKIvroot%/%%1_%%3%%4.crt"
certutil -setreg policy\LDAPIssuercertURL
ldap://%myLDAPserver%/CN=%%7,CN=AIA,CN=Public Key
Services,CN=Services,%%6?cACertificate?base?objectclass=
certificationAuthority
REM
REM Configure CRL publication
REM
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "Days"
REM
REM Disable delta CRL publication
REM
certutil -setreg CA\CRLDeltaPeriodUnits 0
REM
REM Disable issuer name and issuer serial number
REM
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL
REM
REM Restart the CA server service
REM
net stop certsvc & net start certsvc
REM
REM Create Web virtual roots and file shares
REM
certutil.exe -vroot
REM
REM Republish the CRL
REM
certutil -CRL

Zum Seitenanfang

Anhang B: Parameter für eine dreistufige CA-Topologie

In diesem Abschnitt werden alle Parameter beschrieben, die für die Einrichtung einer dreistufigen CA-Topologie erforderlich sind. Die Werte sollten zwischen den Abteilungen im Unternehmen (IT-Abteilung, Rechtsabteilung usw.) abgesprochen werden.

Die Parameter in diesem Abschnitt werden in der Reihenfolge angegeben, in der sie bei der Einrichtung verwendet werden. Die Überschrift enthält den Namen des Parameters, die Tabelle detaillierte Informationen zum Parameter.

Wichtig: Alle Parameter in diesem Abschnitt müssen vorab definiert worden sein, da alle Werte obligatorisch sind.

Konfigurationsparameter für die Stammzertifizierungsstelle

Dieser Abschnitt enthält eine Liste der Parameter, die während der Einrichtung einer eigenständigen Offline-Stammzertifizierungsstelle definiert werden müssen. Die Beispielwerte beziehen sich auf die im vorherigen Abschnitt beschriebene Beispielkonfiguration.

Registrierungsverweise folgen der Syntax, die vom Befehl certutil verwendet wird. Geben Sie an einer Eingabeaufforderung certutil -getreg -? ein, und drücken Sie die Eingabetaste, um weitere Informationen zu den Registrierungswerten zu erhalten.

Länge des Erneuerungsschlüssels (Renewal Key Length) (CA-Zertifikat)

Gültigkeitsdauer der Erneuerung (Renewal Validity Period) (CA-Zertifikat)

Einheit für die Gültigkeitsdauer der Erneuerung (Renewal Validity Period Units) (CA-Zertifikat)

Verteilungspunkt für Sperrliste (Certificate Revocation List (CRL) Distribution Point) (CA-Zertifikat)

Zugriff auf Stelleninformationen (Authority Information Access, AIA) (CA-Zertifikat)

Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) (CA-Zertifikat)

Hashalgorithmus (Hash Algorithm)

Schlüssellänge (Key Length) (CA-Zertifikat)

Allgemeiner Name (Common Name)

Suffix des definierten Namens (Distinguished Name Suffix)

Gültigkeitsdauer (Validity Period) (CA-Zertifikat)

CA-Datenbankpfad (CA Database Path)

CA-Protokolldateipfad (CA Log File Path)

Freigegebener Ordner (Shared Folder)

Verteilungspunkt für Sperrliste (Certificate Revocation List (CRL) Distribution Point)

Zugriff auf Stelleninformationen (Authority Information Access, AIA)

Veröffentlichungsintervall für Sperrlisten (CRL Publication Interval)

Veröffentlichungsintervall für Deltasperrlisten (Delta CRL Publication Interval)

Gültigkeitszeitraum (Validity period)

Konfigurationsparameter für Zwischenzertifizierungsstellen

Dieser Abschnitt enthält eine Liste der Parameter, die während der Einrichtung einer eigenständigen Offline-Stammzertifizierungsstelle definiert werden müssen. Die Beispielwerte beziehen sich auf die im vorherigen Abschnitt beschriebene Beispielkonfiguration.

CA-Richtlinie (CA Policy)

Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) (CA-Zertifikat)

Hashalgorithmus (Hash Algorithm)

Schlüssellänge (Key Length) (CA-Zertifikat)

Allgemeiner Name (Common Name)

CA-Datenbankpfad (CA Database Path)

CA-Protokolldateipfad (CA Log File Path)

Freigegebener Ordner (Shared Folder)

Suffix des definierten Namens (Distinguished Name Suffix)

Sperrlisten-Verteilungspunkt (CRL Distribution Point)

Zugriff auf Stelleninformationen (Authority Information Access, AIA)

Veröffentlichungsintervall für Sperrlisten (CRL Publication Interval)

Veröffentlichungsintervall für Deltasperrlisten (Delta CRL Publication Interval)

Gültigkeitszeitraum (Validity period)

Konfigurationsparameter für ausstellende Zertifizierungsstellen

Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) (CA-Zertifikat)