Vorschläge? Exportieren (0) Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen.
Übersetzung
Original

Neues zu Zertifikatdiensten in Windows Server

 

Betrifft: Windows Server 2012 R2, Windows Server 2012

In diesem Thema werden die AD CS (Active Directory Certificate Services)-Funktionen beschrieben, die in Windows Server 2012 R2 und Windows Server 2012 neu eingeführt oder geändert wurden. Mit AD CS stehen anpassbare Dienste zum Ausstellen und Verwalten von PKI (Public Key-Infrastruktur)-Zertifikaten zur Verfügung. Diese Zertifikate werden in Softwaresicherheitssystemen mit Technologien für öffentliche Schlüssel verwendet.

Inhalte dieses Themas:

Unter Windows Server 2012 R2 bieten Zertifikatdienste eine verbesserte Unterstützung in den folgenden Bereichen:

Feature/Funktionalität

Neu oder verbessert

Beschreibung

Unterstützung von Richtlinienmodulen für den Registrierungsdienst für Netzwerkgeräte

new

Die Verwendung eines Richtlinienmoduls mit dem Registrierungsdienst für Netzwerkgeräte bietet mehr Sicherheit, sodass Benutzer und Geräte Zertifikate aus dem Internet anfordern können.

TPM-Schlüsselnachweis

new

Mit dem TPM-Schlüsselnachweis kann die Zertifizierungsstelle (CA) überprüfen, ob der private Schlüssel durch ein hardwarebasiertes TPM geschützt ist.

Windows PowerShell für Zertifikatdienste

new

Neue Windows PowerShell-Cmdlets sind für Sicherung und Wiederherstellung verfügbar.

Der AD CS-Rollendienst, der Registrierungsdienst für Netzwerkgeräte, ist für gesicherte Netzwerke und vertrauenswürdige Administratoren vorgesehen. Aufgrund dieses Designs kann für die Registrierung ein einzelnes Kennwort oder sogar kein Kennwort verwendet werden, um mehrere Zertifikate anzufordern. Es erfolgt außerdem keine Authentifizierung des angegebenen Werts für den Antragstellernamen.Windows Server 2012 R2 unterstützt jedoch ein Richtlinienmodul für den Registrierungsdienst für Netzwerkgeräte, das zusätzliche Authentifizierung bereitstellt. Daher ist es sinnvoll, diesen Rollendienst in einem Umkreisnetzwerk auszuführen. Diese Konfiguration unterstützt Szenarios wie „Bring Your Own Device“ (BYOD, „Bring dein eigenes Gerät mit“), in denen mobile Geräte, z. B. solche mit iOS oder Android, oder Computer, die keine Domänenmitglieder sind, nun den Registrierungsdienst für Netzwerkgeräte zum Anfordern von Benutzer- und Computerzertifikaten aus dem Internet verwenden können. Dies wird manchmal als drahtlose Registrierung bezeichnet.

Windows Server 2012 R2 besitzt kein Richtlinienmodul. Sie müssen dieses separat von einem Softwarehersteller installieren, der ein Richtlinienmodul bereitstellt, oder ein eigenes Richtlinienmodul schreiben. Bei der Installation eines Richtlinienmoduls von einem Softwarehersteller wird i. d. R. eines von einem Unternehmen verwendet, das Verwaltungsfunktionen für mobile Geräte bereitstellt. Beispielsweise bietet System Center 2012 R2 Configuration Manager ein Richtlinienmodul, das beim Bereitstellen von Zertifikatprofilen erforderlich ist.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Mit dem TPM-Schlüsselnachweis kann die Zertifizierungsstelle (CA) überprüfen, ob der private Schlüssel durch ein hardwarebasiertes TPM geschützt ist und ob das TPM für die Zertifizierungsstelle vertrauenswürdig ist. Diese Funktion verhindert das Exportieren des Zertifikats auf ein nicht autorisiertes Gerät. Außerdem kann die Identität des Benutzers an das Gerät gebunden werden.

Jedes TPM besitzt einen Endorsement Key, der für dieses TPM eindeutig ist. In einigen Fällen haben TPMs ein Endorsement Key-Zertifikat, der es an die ausgebende Zertifizierungsstelle des Herstellers bindet. Nicht alle TPMs unterstützen Schlüsselnachweise, aber bei einer Unterstützung können Sie optional auswählen, ob der Schlüsselnachweis mit dem Endorsement Key oder mithilfe eines Endorsement Key-Zertifikats überprüft wird.

Um TPM-Schlüsselnachweise verwenden zu können, muss das Clientbetriebssystem Windows 8.1 oder Windows Server 2012 R2 sein. Verwenden Sie zum Konfigurieren von TPM-Schlüsselnachweisen eine Zertifikatvorlage der Version 4 mit einer Unternehmens-ZS, und konfigurieren Sie die Einstellungen auf der Registerkarte Schlüsselnachweis. Aktivieren Sie nicht die Einstellung Keine Zertifikate und Anforderungen in der Datenbank der Zertifizierungsstelle speichern auf der Registerkarte Server der Eigenschaften der Zertifikatvorlage, da diese Konfiguration bei TPM-Schlüsselnachweisen nicht unterstützt wird. Darüber hinaus unterstützen eigenständige Zertifizierungsstellen und die Webregistrierung keine TPM-Schlüsselnachweise.

Wenn Sie TPM-Schlüsselnachweise konfigurieren, können Sie steigende Sicherheitsebenen auswählen, indem Sie festlegen, wie der vom Hersteller in das TPM integrierte Endorsement Key überprüft werden soll:

  • Benutzeranmeldeinformationen Bei der Zertifizierungsstelle ist keine zusätzliche Konfiguration erforderlich.

  • Endorsement-Zertifikat. Sie müssen die Stamm- und die ausstellenden Zertifizierungsstellenzertifikate für die TPMs den neuen Zertifikatspeichern bei der Zertifizierungsstelle hinzufügen. Die neuen Zertifikatspeicher sind EKCA für den temporären Speicher und EKRROT für den Stammspeicher.

  • Endorsement Key Sie müssen jeden Endorsement Key für die TPMs einer Genehmigungsliste (EKPUB-Liste) hinzufügen.

System_CAPS_tipTipp

Wenn die Einstellungen auf der Registerkarte Schlüsselnachweis nicht verfügbar sind, überprüfen Sie die folgenden Einstellungen:

  • Auf der Registerkarte Kompatibilität: Die Zertifizierungsstelle ist auf Windows Server 2012 R2 und der Zertifikatsempfänger ist auf Windows 8.1/Windows Server 2012 R2 festgelegt.

  • Auf der Registerkarte Anforderungsbehandlung: Die Kontrollkästchen Exportieren von privatem Schlüssel zulassen und Privaten Schlüssel für die Verschlüsselung archivieren dürfen nicht aktiviert sein.

  • Auf der Registerkate Kryptografie: Die Anbieterkategorie ist auf Schlüsselspeicheranbieter und der Name des Algorithmus ist auf RSA festgelegt. Darüber hinaus muss Für Anforderungen muss einer der folgenden Anbieter verwendet werden auf Kryptografieanbieter für Microsoft-Plattform festgelegt werden.

Weitere Informationen finden Sie in den folgenden Ressourcen:

In Windows Server 2012 R2 sind neue Windows PowerShell-Cmdlets verfügbar. Sie können diese Cmdlets zum Sichern und Wiederherstellen einer Datenbank der Zertifizierungsstelle (CA) verwenden.

Cmdlet-Name

Neu oder verbessert

Beschreibung

Backup-CARoleService

new

Sichern der Zertifizierungsstellen-Datenbank.

Restore-CARoleService

new

Wiederherstellen der Zertifizierungsstellen-Datenbank.

Weitere Informationen zu diesen Cmdlets finden Sie unter Backup-CARoleService und Restore-CARoleService.

Informationen zur Verwendung dieser Cmdlets in einem Migrationsszenario finden Sie in den folgenden Abschnitten von Handbuch für die Migration von Active Directory-Zertifikatdiensten für Windows Server 2012 R2:

Der Server Manager enthält eine zentrale grafische Benutzeroberfläche zum Installieren und Verwalten der AD CS-Serverrolle und ihrer sechs Rollendienste.

Welchen Nutzen bietet diese Änderung?

Die AD CS-Serverrolle und die zugehörigen Rollendienste sind in Server-Manager integriert. Dadurch haben Sie die Möglichkeit, den AD CS-Rollendienst über das Menü Verwalten mithilfe der Option Rollen und Features hinzufügen zu installieren. Sobald die Serverrolle hinzugefügt wurde, wird AD CS im Server-Manager-Dashboard als eine der zu verwaltenden Rollen angezeigt. Auf diese Weise erhalten Sie einen zentralen Ort, an dem Sie AD CS und die Rollendienste bereitstellen und verwalten können. Außerdem können Sie mit dem neuen Server-Manager mehrere Server von einem Ort aus verwalten, die auf den einzelnen Servern installierten AD CS-Rollendienste anzeigen, zugehörige Ereignisse überprüfen und Verwaltungsaufgaben auf den einzelnen Servern ausführen. Weitere Informationen zur Funktionsweise des neuen Server-Managers finden Sie unter Manage multiple, remote servers with Server Manager.

Worin bestehen die Unterschiede?

Zum Hinzufügen der AD CS-Serverrolle können Sie den Link Rollen und Features hinzufügen im Menü Verwalten von Server-Manager verwenden. Der AD CS-Installationsfluss ähnelt dem in der vorherigen Version mit Ausnahme der Aufteilung des Binärdateiinstallationsvorgangs und des Konfigurationsvorgangs. Zuvor waren die Installation und Konfiguration in einem einzigen Assistenten enthalten. Bei der neuen Installationserfahrung installieren Sie zunächst die Binärdateien und starten dann den AD CS-Konfigurations-Assistenten, um die Rollendienste zu konfigurieren, deren Binärdateien bereits installiert waren. Zum Entfernen der AD CS-Serverrolle können Sie den Link Rollen und Features entfernen im Menü Verwalten von Server-Manager verwenden.

Alle AD CS-Rollenservices können mithilfe der Windows PowerShell-Cmdlets für die AD CS-Bereitstellung konfiguriert werden. Diese Cmdlets können auch zum Entfernen der Konfigurationen verwendet werden. Diese neuen Bereitstellungs-Cmdlets werden im Thema AD CS Deployment cmdlets Overview beschrieben. Mit dem AD CS-Verwaltungs-Cmdlet können Sie den Zertifizierungsstellen-Rollendienst verwalten. Die neuen Verwaltungs-Cmdlets werden im Thema AD CS Administration cmdlets Overview beschrieben.

Welchen Nutzen bietet diese Änderung?

Sie können Windows PowerShell zur Skripterstellung für die Bereitstellung beliebiger AD CS-Rollendienste und für die Verwaltungsmöglichkeit des CA-Rollendiensts verwenden.

Worin bestehen die Unterschiede?

Zum Bereitstellen der AD CS-Rollendienste können Sie den Server-Manager oder Windows PowerShell-Cmdlets verwenden.

Alle Versionen von Windows Server 2012 und Windows Server 2012 R2 ermöglichen Ihnen das Installieren der AD CS-Rollendienste.

Welchen Nutzen bietet diese Änderung?

Im Gegensatz zu vorherigen Versionen können Sie AD CS-Rollen unter einer beliebigen Version von Windows Server 2012 oder Windows Server 2012 R2 installieren.

Worin bestehen die Unterschiede?

In Windows Server 2008 R2 galten für verschiedene Rollendienste (früher als Komponenten bezeichnet) unterschiedliche Anforderungen an die Betriebssystemversion, wie unterActive Directory Certificate Services Overview beschrieben. In Windows Server 2012 und Windows Server 2012 R2 funktionieren alle sechs Rollendienste genauso wie in jeder beliebigen Version von Windows Server 2012 oder Windows Server 2012 R2. Der einzige Unterschied besteht darin, dass AD CS samt allen sechs Rollendiensten für die Installation unter jeder beliebigen Version von Windows Server 2012 und Windows Server 2012 R2 verfügbar ist.

Alle sechs AD CS-Rollendienste in Windows Server 2012 und Windows Server 2012 R2 können unter Server Core-Installationen oder den Installationsoptionen der minimalen Serverschnittstelle installiert und ausgeführt werden.

Welchen Nutzen bietet diese Änderung?

Im Gegensatz zu vorherigen Versionen können Sie nun alle AD CS-Rollendienste unter den Installationsoptionen von Server Core oder der minimalen Serverschnittstelle in Windows Server 2012 und Windows Server 2012 R2 ausführen.

Worin bestehen die Unterschiede?

Sie können die AD CS-Rollendienste nun mithilfe von Server-Manager oder Windows PowerShell-Cmdlets bereitstellen, indem Sie lokal am Computer oder per Remoteverbindung über das Netzwerk arbeiten. Zudem bieten Windows Server 2012 und Windows Server 2012 R2 mehrere Installationsoptionen, dank derer Sie die Installation sogar mit einer grafischen Benutzeroberfläche ausführen und später zu einer Server Core-Installation oder zu einer Installation der minimalen Serverschnittstelle wechseln können. Weitere Informationen zu Installationsoptionen finden Sie unter Windows Server Installation Options.

Die Zertifikatregistrierungs-Webdienste sind ein Feature, das in Windows 7 und Windows Server 2008 R2 hinzugefügt wurde. Dieses Feature lässt zu, dass Onlinezertifikatanforderungen aus nicht vertrauenswürdigen Active Directory-Domänendienste-Domänen (Active Directory Domain Services, AD DS) oder selbst von Computern ohne Domänenmitgliedschaft stammen können. AD CS in Windows Server 2012 und Windows Server 2012 R2 basiert insofern auf den Zertifikatregistrierungs-Webdiensten, dass die Möglichkeit zur automatischen Verlängerung von Zertifikaten für Computer hinzugefügt wurde, die zu nicht vertrauenswürdigen AD DS-Domänen gehören oder keiner Domäne hinzugefügt wurden.

Welchen Nutzen bietet diese Änderung?

Administratoren müssen Zertifikate für Computer, die Mitglieder von Arbeitsgruppen sind oder möglicherweise einer anderen AD DS-Domäne oder -Gesamtstruktur angehören, nicht mehr manuell verlängern.

Worin bestehen die Unterschiede?

Zertifikatregistrierungs-Webdienste wird weiterhin wie gewohnt verwendet, aber nun können Computer außerhalb der Domäne ihre Zertifikate mithilfe ihres vorhandenen Zertifikats für die Authentifizierung verlängern.

Weitere Informationen finden Sie im ThemaKey-based renewal. Es sind auch zwei Testumgebungsanleitungen verfügbar, in denen die Anwendung dieser schlüsselbasierten Erneuerung veranschaulicht wird:

  1. Testumgebungsanleitung: Demonstrieren der zertifikatschlüsselbasierten Erneuerung

  2. Testumgebungsanleitung – Minimodul: Gesamtstrukturübergreifende Zertifikatregistrierung mithilfe von Zertifikatregistrierungs-Webdiensten

Mit AD CS in Windows Server 2012 und Windows Server 2012 R2 werden Zertifikatvorlagen der Version 4 eingeführt. Diese Vorlagen weisen gegenüber vorherigen Vorlagenversionen einige Unterschiede auf. Zertifikatvorlagen der Version 4:

  • unterstützen Kryptografiedienstanbieter (Cryptographic Service Provider, CSPs) und Schlüsseldienstanbieter (Key Service Providers, KSPs).

  • können so festgelegt werden, dass eine Verlängerung mit demselben Schlüssel erforderlich ist.

  • sind für die Verwendung in Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 verfügbar.

  • geben die mindestens erforderlichen Betriebssysteme für Zertifizierungsstellen und Zertifikatclients an, von denen die Vorlage verwendet werden kann.

Um den Administratoren bei der Einteilung zu helfen, welche Features von welcher Betriebssystemversion unterstützt werden, wurde der Registerkarte der Zertifikatvorlageneigenschaften die Registerkarte Kompatibilität hinzugefügt.

Welchen Nutzen bietet diese Änderung?

Die neuen Zertifikatvorlagen der Version 4 bieten zusätzliche Funktionen wie die Erzwingung der Verlängerung mit demselben Schlüssel (nur für Zertifikatclients mit Windows 8, Windows 8.1, Windows Server 2012 oder Windows Server 2012 R2 verfügbar). Auf der neuen Registerkarte Kompatibilität können Administratoren unterschiedliche Kombinationen aus Betriebssystemversionen für die Zertifizierungsstelle und Zertifikatclients festlegen und nur die Einstellungen anzeigen, die mit diesen Clientversionen kompatibel sind.

Worin bestehen die Unterschiede?

Die Registerkarte Kompatibilität wird auf der Benutzeroberfläche unter den Eigenschaften der "Zertifikatvorlage" angezeigt. Auf dieser Registerkarte können Sie die mindestens erforderlichen Betriebssystemversionen für die Zertifizierungsstelle und den Zertifikatclient auswählen. Bei der Konfiguration der Registerkarte Kompatibilität werden mehrere Aktionen ausgeführt:

  • In Abhängigkeit der für den Zertifikatclient und die Zertifizierungsstelle ausgewählten Betriebssystemversionen werden Optionen in den Zertifikatvorlageneigenschaften als nicht verfügbar markiert.

  • Bei Vorlagen der Version 4 wird mit ihr bestimmt, von welchen Betriebssystemversionen die Vorlage verwendet werden kann.

Für Clients vor Windows 8 und Windows Server 2012 können die neuen Vorlagen der Version 4 nicht verwendet werden.

System_CAPS_noteHinweis

Auf der Registerkarte Kompatibilität wird der folgende Hinweis angezeigt: Diese Einstellungen verhindern möglicherweise nicht, dass frühere Betriebssystemversionen diese Vorlage verwenden. Diese Aussage beinhaltet, dass Kompatibilitätseinstellungen keine einschränkende Wirkung auf Vorlagen der Version 1, Version 2 oder Version 3 haben und die Registrierung möglicherweise wie zuvor fortgesetzt wird. Wenn beispielsweise auf der Registerkarte Kompatibilität die minimale Client-Betriebssystemversion auf Windows Vista mit einer Vorlage der Version 2 festgelegt ist, kann sich ein Windows XP-Zertifikatclient mithilfe der Vorlage der Version 2 dennoch für ein Zertifikat registrieren.

Weitere Informationen zu diesen Änderungen finden Sie unter Certificate Template Versions and Options.

AD CS in Windows Server 2012 und Windows Server 2012 erlaubt die Konfiguration von Zertifikaten für eine Erneuerung mit demselben Schlüssel. Dadurch kann dieselbe Sicherheitsstufe des ursprünglichen Schlüssels während seines gesamten Lebenszyklus beibehalten werden.Windows Server 2012 und Windows Server 2012 unterstützen das Generieren von TPM (Trusted Platform Module)-geschützten Schlüsseln mithilfe von TPM-basierten Schlüsselspeicheranbietern (Key Storage Providers, KSPs). Der Vorteil der Verwendung TPM-basierter Schlüsselspeicheranbieter liegt darin, dass es keine Exportmöglichkeit für Schlüssel gibt, die mithilfe des Anti-Hammering-Mechanismus von TPMs gesichert werden. Administratoren können Zertifikatvorlagen so konfigurieren, dass Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 den TPM-basierten Schlüsselspeicheranbietern zum Generieren von Schlüsseln eine höhere Priorität erteilt. Außerdem können Administratoren beim Verwenden der Verlängerung mit demselben Schlüssel sicher sein, dass der Schlüssel nach der Verlängerung weiterhin im TPM verbleibt.

System_CAPS_noteHinweis

Wenn die PIN (Personal Identification Number) zu oft falsch eingegeben wird, wird die Anti-Hammering-Logik des TPM aktiviert. Bei der Anti-Hammering-Logik handelt es sich um eine Software- oder Hardwaremethode, die die Schwierigkeit bzw. die Kosten eines Brute-Force-Angriffs auf eine PIN erhöht, indem sie PIN-Eingaben erst nach Ablauf einer bestimmten Zeit akzeptiert.

Welchen Nutzen bietet diese Änderung?

Mit diesem Feature kann ein Administrator die Verlängerung mit demselben Schlüssel erzwingen, wodurch Verwaltungskosten reduziert werden (wenn Schlüssel automatisch verlängert werden) und die Schlüsselsicherheit erhöht wird (wenn die Schlüssel mithilfe von TPM-basierten Schlüsselspeicheranbietern gespeichert werden).

Worin bestehen die Unterschiede?

Clients, die Zertifikate aus Vorlagen erhalten, die für die Verlängerung mit demselben Schlüssel konfiguriert sind, müssen ihre Zertifikate mithilfe desselben Schlüssels verlängern, sonst tritt bei der Verlängerung ein Fehler auf. Zudem ist diese Option nur für Zertifikatclients mit Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 verfügbar.

System_CAPS_noteHinweis
  • Weitere Informationen finden Sie unter Certificate Renewal with the Same Key.

  • Wenn die Option Renew with the same key in einer Zertifikatvorlage und außerdem die nachfolgende Schlüsselarchivierung (Archive subject's encryption private key) aktiviert ist, werden einige erneuerte Zertifikate möglicherweise nicht archiviert. Weitere Informationen zu diesem Fall und seiner Lösung finden Sie unter Key Archival and renew with the same key.

Wenn die Option Mit dem gleichen Schlüssel erneuern für eine Zertifikatvorlage und außerdem die nachfolgende Schlüsselarchivierung (Privaten Schlüssel für die Verschlüsselung archivieren) aktiviert ist, werden erneuerte Zertifikate nicht archiviert. Weitere Informationen zu diesem Fall und seiner Lösung finden Sie unter Key Archival and renew with the same key.

Internationalisierte Namen sind Namen mit Zeichen, die in ASCII nicht dargestellt werden können. AD CS in Windows Server 2012 und Windows Server 2012 R2 unterstützt internationalisierte Domänennamen (Internationalized Domain Names, IDNs) in verschiedenen Szenarios.

Welchen Nutzen bietet diese Änderung?

Die folgenden IDN-Szenarios werden nun unterstützt:

  • Zertifikatregistrierung für Computer mit IDNs

  • Generieren und Absenden einer Zertifikatanforderung mit einem IDN mithilfe des Befehlszeilentools "certreq.exe"

  • Veröffentlichen von Zertifikatsperrlisten (Certificate Revocation List, CRL) und des Online Certificate Status-Protokoll (OCSP) auf Servern mit IDNs

  • Die Benutzerschnittstelle Zertifikat unterstützt IDNs

  • Das MMC-Snap-In "Zertifikat" lässt auch IDNs in Zertifikateigenschaften zu

Worin bestehen die Unterschiede?

Wie zuvor beschrieben ist die Unterstützung für IDNs eingeschränkt.

Wenn eine Zertifizierungsstelle (Certification Authority, CA) eine Zertifikatanforderung empfängt, kann die Verschlüsselung für die Anforderung von der CA mithilfe von RPC_C_AUTHN_LEVEL_PKT erzwungen werden, wie im MSDN-Artikel Authentication-Level Constants beschrieben. In Windows Server 2008 R2 und früheren Versionen ist diese Einstellung für die Zertifizierungsstelle nicht standardmäßig aktiviert. In einer Windows Server 2012- oder Windows Server 2012 R2-Zertifizierungsstelle ist diese erweiterte Sicherheitseinstellung standardmäßig aktiviert.

Welchen Nutzen bietet diese Änderung?

Die Zertifizierungsstelle erzwingt die erhöhte Sicherheit in den an sie gesendeten Anforderungen. Bei dieser höheren Sicherheitsstufe müssen die Pakete, die ein Zertifikat anfordern, verschlüsselt sein, damit sie nicht abgefangen und gelesen werden können. Ist diese Einstellung nicht aktiviert, können alle Personen mit Zugriff auf das Netzwerk mithilfe eines Netzwerkanalysetools Pakete lesen, die an die und von der Zertifizierungsstelle gesendet werden. Das bedeutet, dass Informationen verfügbar gemacht werden könnten, die möglicherweise eine Datenschutzverletzung darstellen. Dazu gehören beispielsweise die Namen der anfordernden Benutzer oder Computer, die Typen von Zertifikaten, für die sie sich registrieren, die zugehörigen öffentlichen Schlüssel usw. Innerhalb einer Gesamtstruktur oder Domäne ist die Verbreitung dieser Daten für die meisten Organisationen möglicherweise kein Grund zur Sorge. Wenn Angreifer jedoch Zugriff auf den Netzwerkdatenverkehr erlangen, könnten interne Unternehmensstrukturen und -aktivitäten gesammelt werden, die wiederum für gezieltere Social Engineering- oder Phishing-Angriffe verwendet werden könnten.

Die Befehle zum Aktivieren der erweiterten Sicherheitsstufe von RPC_C_AUTHN_LEVEL_PKT in den Zertifizierungsstellen von Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 oder Windows Server 2008 R2 lauten wie folgt:

certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Zum Starten der Zertifizierungssstelle:
net stop certsvc
net start certsvc

Wenn Sie noch über Windows XP-Clientcomputer verfügen, die Zertifikate von einer Zertifizierungsstelle anfordern müssen, für die die Einstellung aktiviert ist, haben Sie zwei Möglichkeiten:

  1. Aktualisieren Sie die Windows XP-Clients auf ein neueres Betriebssystem.

  2. Setzen Sie die Sicherheit der Zertifizierungsstelle herab, indem Sie die folgenden Befehle ausführen:

    So setzen Sie die Zertifizierungsstellensicherheit für die Kompatibilität mit Windows XP-Clients herab

    1. certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

    2. net stop certsvc

    3. net start certsvc

Worin bestehen die Unterschiede?

Windows XP-Clients sind mit dieser für eine Windows Server 2012- oder Windows Server 2012 R2-Zertifizierungsstelle standardmäßig aktivierten höheren Sicherheitseinstellung nicht kompatibel. Bei Bedarf können Sie die Sicherheitseinstellung wie zuvor beschreiben herabsetzen.

Die Zertifikatdienste in Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 können für die Nutzung der Active Directory-Domänendienststandorte (AD DS) konfiguriert werden, um die Anforderungen von Zertifikatdienst-Clientanforderungen zu optimieren. Diese Funktion ist weder auf Zertifizierungsstellen- noch auf PKI-Clientcomputern standardmäßig aktiviert.

System_CAPS_noteHinweis

Informationen zur Aktivierung der AD DS-Standortinformationen finden Sie im TechNet-Wiki-Artikel AD DS Site Awareness for AD CS and PKI Clients.

Welchen Nutzen bietet diese Änderung?

Mithilfe dieser Änderung können Zertifikatclients mit Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 am lokalen AD DS-Standort eine Zertifizierungsstelle ermitteln.

Worin bestehen die Unterschiede?

Beim Registrieren für ein vorlagenbasiertes Zertifikat fragt der Client bei AD DS die Vorlage und die Zertifizierungsstellenobjekte ab. Anschließend wird vom Client ein DsGetSiteName-Funktionsaufruf verwendet, um seinen eigenen Standortnamen abzurufen. Für Zertifizierungsstellen, für die das msPKI-Site-Name-Attribut bereits festgelegt wurde, werden vom Zertifikatdienstclient die AD DS-Standortverknüpfungskosten vom Clientstandort zu den einzelnen Zertifizierungsstellenstandorten ermittelt. Zur Ermittlung wird ein DsQuerySitesByCost-Funktionsaufruf verwendet. Vom Zertifizierungsdienstclient werden die zurückgegebenen Standortkosten verwendet, um die Zertifizierungsstellen zu priorisieren, die für den Client die Berechtigung "Registrieren" zulassen und die jeweilige Zertifikatvorlage unterstützen. Die Zertifizierungsstellen mit den höheren Kosten werden nach Möglichkeit zuletzt kontaktiert (nur falls vorherige Zertifizierungsstellen nicht verfügbar sind).

System_CAPS_noteHinweis

Von einer Zertifizierungsstelle werden möglicherweise keine Standortkosten zurückgegeben, wenn das msPKI-Site-Name-Attribut für die Zertifizierungsstelle nicht festgelegt ist. Falls für eine einzelne Zertifizierungsstelle keine Standortkosten verfügbar sind, werden ihr die höchstmöglichen Kosten zugewiesen.

Bislang wurde ein PKCS#12-Standardformat (auch bekannt als PFX) nur mit einem Kennwort geschützt. Dies hatte folgende Nachteile:

  • Schwierig zu automatisieren

  • Nicht sehr sicher, da i. d. R. der Administrator ein unsicheres Kennwort verwendet hat

  • Schwierig von mehreren Benutzern gemeinsam zu nutzen

Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 können Zertifikate und die zugehörigen privaten Schlüssel durch Kombinieren eines vorhandenen PFX-Formats mit einem neuen Datenschutzfeature schützen. Dies ermöglicht das Verschlüsseln des Inhalts der PFX-Datei mit einem Schlüssel, der zu einer Gruppe oder einer Einzelperson gehört, anstelle des Kennwortschutzes.

System_CAPS_noteHinweis

Welchen Nutzen bietet diese Änderung?

Mit diesem Feature haben Administratoren folgende Möglichkeiten:

  • Bereitstellen und Verwalten von Zertifikaten und Beheben von Problemen im Zusammenhang mit diesen – remote und über Serverfarmen hinweg – mit Windows PowerShell.

  • Sicheres Freigeben von Zertifikaten und Schlüsseln in Serverfarmen mit Windows Server 2012 oder Windows Server 2012 R2 mithilfe von Windows-APIs.

Frühere Versionen von Windows können dieses PFX nutzen, da vom Betriebssystem intern ein sicheres zufälliges Kennwort zugewiesen wird. Das Kennwort ist in der PFX-Datei enthalten und durch eine Reihe von Sicherheits-IDs (SIDs) mit Datenschutz-APIs geschützt. Jeder Benutzer mit Zugriff auf die PFX-Datei kann dieses Kennwort anzeigen und mit früheren Versionen von Windows verwenden.

Worin bestehen die Unterschiede?

Eine PFX-Datei kann jetzt durch einen Sicherheitsprinzipal anstelle von nur einem Kennwort geschützt werden. Die Benutzeroberfläche für den Zertifikatexport wurde aktualisiert, um die Auswahl eines Sicherheitsprinzipals während des Exports zu ermöglichen.

In Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 stellen Zertifikate Lebenszyklusbenachrichtigungen im MY-Speicher auf der Ebene der Zertifikatregistrierungs-API und von Windows PowerShell bereit. Die Benachrichtigungen umfassen Ablauf, Löschung, Neuerstellung, Erneuerung, Ersatz, in Ablaufdatumnähe, Archivierung und Export. Administratoren und Entwickler können Zertifikate und die zugeordneten privaten Schlüssel remote mithilfe von Windows PowerShell verwalten (anzeigen, installieren, kopieren, anfordern und löschen). Dieses Feature ermöglicht den Start eines Skripts oder einer ausführbaren Datei in Reaktion auf eine Lebenszyklusbenachrichtigung für ein Zertifikat.

System_CAPS_noteHinweis

Welchen Nutzen bietet diese Änderung?

Für Anwendungs- und Serverauslastungs-Entwickler, die Zertifikate in ihren Produkten verwenden, ist die Integration des Zertifikatlebenszyklus in Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 einfach und zuverlässig – und kann remote ausgeführt werden. Entwickler können Anwendungen entwickeln, die sich jederzeit selbst neu konfigurieren, wenn ein Zertifikat erneuert oder durch ein anderes Zertifikat ersetzt wird. Dies kann durch automatische Nachweise oder durch den Administrator manuell bzw. mithilfe von Skripts ausgeführt werden. Die Investitionen zur Integration der Verwaltungsschnittstellen für Zertifikate ist sehr gering.

Für den Administrator der Anwendungen, die Zertifikate verwenden, werden Windows 8-, Windows 8.1-, Windows Server 2012- und Windows Server 2012 R2-Zertifikate automatisch durch die Anwendung verwendet. Dies erfolgt entweder, weil die Anwendung Windows 8-, Windows 8.1-, Windows Server 2012- und Windows Server 2012 R2-Zertifikatbenachrichtigungen integriert oder wenn das Administratorskript durch ein Zertifikatereignis ausgelöst wird.

Worin bestehen die Unterschiede?

Es können jetzt Benachrichtigungen an Systemadministratoren gesendet werden, bevor Zertifikate ablaufen.

Die Windows Server-Sicherung kann bei der Zertifizierungsstelle (CA) installiert werden, um eine Systemstatussicherung zu erstellen, die auch die privaten Schlüssel der Zertifizierungsstelle enthält.

Worin bestehen die Unterschiede?

In Windows Server 2012 und Windows Server 2012 R2 sichert das Systemstatussicherungs-Feature automatisch den privaten Schlüssel von Zertifizierungsstellen, wenn ein Administrator oder Sicherungsoperator die Windows Server-Sicherung verwendet, um eine Systemstatussicherung durchzuführen.

Worin bestehen die Unterschiede?

Die Windows Server-Sicherung umfasst nun die privaten Schlüssel der Zertifizierungsstelle.

System_CAPS_tipTipp
Anzeigen:
© 2016 Microsoft