PKI-Entwurfsüberlegungen bei der Verwendung von Active Directory-Zertifikatdiensten

Es gibt einige Dinge, die Sie bei der Planung der Bereitstellung einer Public Key-Infrastruktur mit Active Directory-Zertifikatdiensten berücksichtigen sollten. Hier finden Sie, was Sie benötigen, um Ihre PKI-Umgebung erfolgreich zu installieren und zu konfigurieren.

Auf hoher Ebene sollten Sie:

• Planen Sie eine Public Key-Infrastruktur (Public Key Infrastructure, PKI), die für Ihre Organisation geeignet ist.
• Installieren und konfigurieren Sie ein Hardware Security Module (HSM) gemäß den ANWEISUNGEN des HSM-Herstellers, wenn Sie planen, eines zu verwenden.
• Erstellen Sie eine geeignete CAPolicy.inf-Datei, falls Sie die Standardinstallationseinstellungen ändern möchten.
• Auswählen von kryptografischen Optionen
• Ermitteln des CA-Namens
• Gültigkeitszeitraum ermitteln
• CA-Datenbank auswählen
• Einstellungen für den Zugriff auf Autoritätsinformationen und den Zertifikatsperrlistenverteilungspunkt

Plan für PKI

Um sicherzustellen, dass Ihre Organisation ihre Active Directory-Zertifikatdienste (AD CS)-Installation vollständig nutzen kann, müssen Sie die PKI-Bereitstellung entsprechend planen. Sie sollten festlegen, wie viele CAs Sie benötigen und in welcher Konfiguration, bevor Sie eine Zertifizierungsstelle installieren. Benötigen Sie z. B. eine Enterprise-Stammzertifizierungsstelle oder eine eigenständige Stammzertifizierungsstelle? Wie werden Zertifikatgenehmigungsanforderungen verarbeitet? Wie verwalten Sie die Zertifikatsperrung? Das Erstellen eines geeigneten PKI-Designs kann zeitaufwändig sein, ist aber für den Erfolg Ihrer PKI wichtig.

Verwenden eines HSM

Ein HSM ist ein dediziertes Hardwaregerät, das separat vom Betriebssystem verwaltet wird. Diese Module bieten zusätzlich zu einem dedizierten kryptografischen Prozessor einen sicheren Hardwarespeicher für Zertifizierungsstellenschlüssel, um die Signierung und Verschlüsselung von Vorgängen zu beschleunigen. Das Betriebssystem nutzt das HSM über die CryptoAPI-Schnittstellen und das HSM fungiert als kryptografisches Dienstanbietergerät (CSP).

HSMs sind in der Regel PCI-Adapter, aber sie sind auch als netzwerkbasierte Appliances, serielle Geräte und USB-Geräte verfügbar. Wenn eine Organisation plant, zwei oder mehr CAs zu implementieren, können Sie ein einzelnes netzwerkbasiertes HSM installieren und für mehrere CAs freigeben.

Um eine Zertifizierungsstelle mithilfe eines HSM einzurichten, muss das HSM installiert und konfiguriert werden, bevor Sie CAs mit Schlüsseln einrichten, die auf dem HSM gespeichert werden müssen.

Betrachten Sie eine CAPolicy.inf-Datei

Die CAPolicy.inf Datei ist nicht erforderlich, um AD CS zu installieren, kann jedoch verwendet werden, um die Einstellungen der Zertifizierungsstelle anzupassen. Die CAPolicy.inf-Datei enthält verschiedene Einstellungen, die bei der Installation der Zertifizierungsstelle und beim Erneuern des Zertifizierungsstellenzertifikats verwendet werden. Die CAPolicy.inf Datei muss erstellt und im %systemroot% Verzeichnis (typischerweise C:\Windows) gespeichert werden, damit sie verwendet werden kann.

Die Einstellungen, die Sie in die CAPolicy.inf Datei aufnehmen, hängen weitgehend vom Bereitstellungstyp ab, den Sie erstellen möchten. Eine Stammzertifizierungsstelle kann z. B. eine CAPolicy.inf-Datei aufweisen, die wie folgt aussieht:

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

Auswählen von kryptografischen Optionen

Die Auswahl kryptografischer Optionen für eine Zertifizierungsstelle kann erhebliche Auswirkungen auf Sicherheit, Leistung und Kompatibilität für diese Zertifizierungsstelle haben. Obwohl die standardmäßigen kryptografischen Optionen für die meisten CAs geeignet sind. Die Möglichkeit, benutzerdefinierte Optionen zu implementieren, kann für Administratoren und Anwendungsentwickler mit einem komplexeren Verständnis der Kryptografie und der Notwendigkeit dieser Flexibilität nützlich sein. Kryptografische Optionen können mithilfe von Kryptografiedienstanbietern (CSPs) oder Schlüsselspeicheranbietern (Key Storage Providers, KSPs) implementiert werden.

CSPs sind Hardware- und Softwarekomponenten in Windows-Betriebssystemen, die generische kryptografische Funktionen bereitstellen. CSPs können geschrieben werden, um verschiedene Verschlüsselungs- und Signaturalgorithmen bereitzustellen.

Wenn Sie den Anbieter, den Hashalgorithmus und die Schlüssellänge auswählen, sollten Sie sorgfältig überlegen, welche kryptografischen Optionen die Anwendungen und Geräte, die Sie verwenden möchten, unterstützen können. Obwohl es eine bewährte Methode ist, die stärksten Sicherheitsoptionen auszuwählen, können nicht alle Anwendungen und Geräte diese unterstützen.

Das Zulassen der Administratorinteraktion, wenn der private Schlüssel von der CA (Zertifizierungsstelle) zugegriffen wird, ist eine Option, die typischerweise mit Hardware Security Modules (HSMs) verwendet wird. Mit dieser Option kann der kryptografische Anbieter den Benutzer zur zusätzlichen Authentifizierung auffordern, wenn auf den privaten Schlüssel der Zertifizierungsstelle zugegriffen wird. Beispielsweise muss der Administrator vor jedem kryptografischen Vorgang ein Kennwort eingeben.

Die integrierten kryptografischen Anbieter unterstützen bestimmte Schlüssellängen und Hashalgorithmen, wie in der folgenden Tabelle beschrieben.

Cryptographic provider	Key lengths	Hash algorithm
Microsoft Base Cryptographic Provider v1.0	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Microsoft Base DSS Kryptografieanbieter	- 512 - 1024	SHA1
Microsoft Base-Smartcard-Kryptoanbieter	- 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Microsoft Enhanced Cryptographic Provider v1.0	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Microsoft Strong Cryptographic Provider (Starker kryptographischer Anbieter)	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
RSA#Microsoft Software-Schlüssel-Speicheranbieter	- 512 - 1024 - 2048 - 4096	- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5
DSA#Microsoft Software-Schlüssel-Speicheranbieter	- 512 - 1024 - 2048	SHA1
ECDSA_P256#Microsoft-Software-Schlüssel-Speicheranbieter	256	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P384#Microsoft-Softwareschlüsselspeicheranbieter	384	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P521#Microsoft-Softwareschlüsselspeicheranbieter	521	- SHA1 - SHA256 - SHA384 - SHA512
RSA#Microsoft-Smartcard-Schlüsselspeicheranbieter	- 1024 - 2048 - 4096	- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5
ECDSA_P256#Microsoft Smartcard-Schlüsselspeicheranbieter	256	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P384#Microsoft-Smartcard-Schlüsselspeicheranbieter	384	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P521#Microsoft-Smartcard-Schlüsselspeicheranbieter	521	- SHA1 - SHA256 - SHA384 - SHA512

Ermitteln des Zertifizierungsstellennamens

Bevor Sie Zertifizierungsstellen in Ihrer Organisation konfigurieren, sollten Sie eine Zertifizierungsstellenbenennungskonvention einrichten.

Sie können einen Namen mithilfe eines beliebigen Unicode-Zeichens erstellen, aber Sie können den ANSI-Zeichensatz verwenden, wenn die Interoperabilität ein Problem darstellt. Beispielsweise können bestimmte Routertypen den Netzwerkgeräteregistrierungsdienst nicht verwenden, um sich für Zertifikate zu registrieren, wenn der Name der Zertifizierungsstelle Sonderzeichen wie einen Unterstrich enthält.

Wenn Sie nicht lateinische Zeichen (z. B. kyrillische, arabische oder chinesische Zeichen) verwenden, muss ihr Ca-Name weniger als 64 Zeichen enthalten. Wenn Sie nur nicht lateinische Zeichen verwenden, darf ihr Ca-Name maximal 37 Zeichen lang sein.

In Active Directory Domain Services (AD DS) wird der Name, den Sie angeben, wenn Sie einen Server als Zertifizierungsstelle konfigurieren, zum allgemeinen Namen der Zertifizierungsstelle. Der allgemeine Name ist in jedem Zertifikat enthalten, das von der Zertifizierungsstelle ausgegeben wird. Aus diesem Grund ist es wichtig, dass Sie nicht den vollqualifizierten Domänennamen für den gemeinsamen Namen der Zertifizierungsstelle verwenden. Auf diese Weise können böswillige Benutzer, die eine Kopie eines Zertifikats erhalten, den vollqualifizierten Domänennamen der Zertifizierungsstelle nicht identifizieren und verwenden, um eine potenzielle Sicherheitslücke zu schaffen.

Der Name der Zertifizierungsstelle sollte nicht mit dem Namen des Computers (NetBIOS oder DNS-Name) identisch sein. Außerdem können Sie den Namen eines Servers nicht ändern, nachdem Active Directory-Zertifikatdienste (AD CS) installiert wurden, ohne alle Zertifikate zu ungültig machen, die von der Zertifizierungsstelle ausgestellt wurden.

Um den Servernamen nach der Installation von AD CS zu ändern, müssen Sie die Zertifizierungsstelle deinstallieren, den Namen des Servers ändern, die Zertifizierungsstelle mit denselben Schlüsseln neu installieren und die Registrierung so ändern, dass die vorhandenen Zertifizierungsstellenschlüssel und -datenbank verwendet werden. Sie müssen eine Zertifizierungsstelle nicht erneut installieren, wenn Sie eine Domäne umbenennen. Sie müssen die Zertifizierungsstelle jedoch neu konfigurieren, um die Namensänderung zu unterstützen.

Gültigkeitszeitraum ermitteln

Zertifikatbasierte Kryptografie verwendet Kryptografie mit öffentlichem Schlüssel, um Daten zu schützen und zu signieren. Im Laufe der Zeit konnten Angreifer Daten abrufen, die mit dem öffentlichen Schlüssel geschützt wurden, und versuchen, den privaten Schlüssel daraus abzuleiten. Angesichts ausreichender Zeit und Ressourcen könnte dieser private Schlüssel kompromittiert werden, was dazu führen würde, dass alle geschützten Daten ungeschützt sind. Auch die Namen, die durch ein Zertifikat garantiert werden, müssen möglicherweise im Laufe der Zeit geändert werden. Da ein Zertifikat eine Bindung zwischen einem Namen und einem öffentlichen Schlüssel ist, sollte das Zertifikat bei jeder Änderung erneuert werden.

Jedes Zertifikat hat einen Gültigkeitszeitraum. Nach Ablauf des Gültigkeitszeitraums gilt das Zertifikat nicht mehr als zulässiges oder verwendbares Berechtigungsnachweis.

Zertifizierungsstellen können keine Zertifikate ausstellen, die über ihren eigenen Gültigkeitszeitraum hinausgehen. Eine bewährte Methode besteht darin, das Zertifizierungsstellenzertifikat zu erneuern, wenn die Hälfte des Gültigkeitszeitraums verstrichen ist. Sie sollten dieses Datum bei der Installation einer Zertifizierungsstelle planen und darauf achten, dass es als zukünftige Aufgabe erfasst wird.

CA-Datenbank auswählen

Die Datenbank der Zertifizierungsstelle ist eine Datei auf der Festplatte. Zusätzlich zu dieser Datei dienen andere Dateien als Transaktionsprotokolle, und sie erhalten alle Änderungen an der Datenbank, bevor die Änderungen vorgenommen werden. Da häufig und gleichzeitig auf diese Dateien zugegriffen werden kann, sollten Sie die Datenbank- und Transaktionsprotokolle auf separaten Volumes speichern.

Der Speicherort der Zertifikatdatenbank und Protokolldateien wird am folgenden Registrierungsspeicherort gespeichert:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Die Registrierung enthält die folgenden Werte:

• DBDirectory
• DBLogDirectory
• DBSystemDirectory
• DBTempDirectory

Einstellungen für den Zugriff auf Autoritätsinformationen und den Zertifikatsperrlistenverteilungspunkt

Nachdem eine Stamm- oder untergeordnete Zertifizierungsstelle installiert wurde, sollten Sie die Erweiterungen für Authority Information Access (AIA) und CRL-Verteilungspunkt (CDP) konfigurieren, bevor die Zertifizierungsstelle Zertifikate ausgibt. Die AIA-Erweiterung bestimmt, wo sich die aktuellen Zertifikate der ZS befinden. Die CDP-Erweiterung bestimmt, wo sich die aktuellen Zertifikatsperrlisten befinden, die von dieser ZS signiert wurden. Diese Erweiterungen gelten für alle Zertifikate, die von dieser Zertifizierungsstelle ausgestellt werden.

Durch das Konfigurieren dieser Erweiterungen wird sichergestellt, dass diese Informationen in jedem Zertifikat enthalten sind, das die Zertifizierungsstelle ausgibt, damit sie für alle Clients verfügbar ist. Die Verwendung der Erweiterungen führt zu weniger Fehlern aufgrund nicht überprüfter Zertifikatketten oder Zertifikatsperren, was zu erfolglosen VPN-Verbindungen, fehlgeschlagenen Smartcardanmeldungen oder nicht überprüften E-Mail-Signaturen führen kann.

Als CA-Administrator können Sie CRL-Verteilungspunkte sowie die Standorte für die Ausstellung von CDP- und AIA-Zertifikaten hinzufügen, entfernen oder ändern. Das Ändern der URL für einen CRL-Verteilungspunkt wirkt sich nur auf neu ausgestellte Zertifikate aus. Zuvor ausgestellte Zertifikate verweisen weiterhin auf den ursprünglichen Speicherort. Deshalb sollten Sie diese Speicherorte einrichten, bevor Ihre Zertifizierungsstelle Zertifikate verteilt.

Beachten Sie beim Konfigurieren von CDP-Erweiterungs-URLs die folgenden Richtlinien:

• Vermeiden Sie es, Deltazertifikatsperrlisten in Offlinestammzertifizierungsstellen zu veröffentlichen. Da Sie nicht viele Zertifikate auf einer Offline-Root-CA widerrufen, wird wahrscheinlich keine Delta-CRL benötigt.
• Passen Sie die Standard-LDAP://- und http://-URL-Speicherorte auf der Registerkarte "Erweiterungen" der Registerkarte "Eigenschaften" der Zertifizierungsstelle entsprechend Ihren Anforderungen an.
• Veröffentlichen Sie eine CRL auf einem HTTP-Internet- oder Extranetspeicherort, damit Benutzer und Anwendungen außerhalb der Organisation eine Zertifikatüberprüfung durchführen können. Sie können die LDAP- und HTTP-URLs für CDP-Speicherorte veröffentlichen, damit Clients CRL-Daten mit HTTP und LDAP abrufen können.
• Denken Sie daran, dass Windows-Clients immer die Liste der URLs in sequenzieller Reihenfolge abrufen, bis eine gültige CRL abgerufen wird.
• Verwenden Sie HTTP-CDP-Speicherorte, um barrierefreie CRL-Speicherorte für Clients bereitzustellen, die Nicht-Windows-Betriebssysteme ausführen.

Next steps

Weitere Informationen zur Bereitstellung von AD CS finden Sie unter Implementieren und Verwalten von Active Directory-Zertifikatdiensten.