Wie man eine ML-DSA-CA-Hierarchie in Microsoft AD CS erstellt

Kurz gesagt: Der Aufbau einer ML-DSA-Zertifizierungsstellenhierarchie in Active Directory CS unter Windows Server 2025 folgt dem gleichen zweistufigen Stamm- und Unterzertifizierungsstellenmuster wie jede klassische PKI, jedoch mit drei wesentlichen Unterschieden: Der Parameter „KeyLength“ wird in Bit angegeben, die von der tatsächlichen Schlüssellänge des Algorithmus abgeleitet sind (20,736 Bit für ML-DSA-87), der CryptoProviderName muss explizit auf den ML-DSA-CNG-Anbieter verweisen, und es gibt keinen direkten Upgrade-Pfad. Daher muss eine neue Hierarchie parallel zur Produktionsumgebung eingerichtet werden und kann keine bestehende Zertifizierungsstelle modifizieren. Sie benötigen zwei Server mit Windows Server 2025 und dem Sicherheitsupdate vom Mai 2026 (KB5087539) oder höher – einen für die Stamm- und einen für die Unterzertifizierungsstelle – sowie einen in die Domäne eingebundenen Windows 11-Client mit dem Update vom Oktober 2025 oder höher für Registrierungstests. Diese Anleitung beschreibt die Konfiguration: Voraussetzungen, Einrichtung von Stamm- und Unterzertifizierungsstellen, Zertifikatvorlagen, Validierung und die Überwachung nach der Bereitstellung.

Unser Leitfaden zur ML-DSA-Unterstützung für Ihre Microsoft PKI erläutert die strategische Bedeutung dieser Funktion. Dieser Leitfaden dient als praktischer Begleiter: Er enthält die konkreten Befehle und Konfigurationsschritte zum Einrichten einer funktionierenden ML-DSA-CA-Hierarchie in einer Labor- oder Pilotumgebung.

Wichtige Erkenntnisse

• Für eine ML-DSA-CA-Hierarchie ist Windows Server 2025 mit dem Sicherheitsupdate vom Mai 2026 (KB5087539) oder höher sowohl auf dem Stamm- als auch auf den untergeordneten CA-Servern erforderlich.
• PowerShell's Install-AdcsCertificationAuthority benötigt KeyLength in Bits, berechnet aus der tatsächlichen Schlüssellänge des ML-DSA-Parametersatzes, und einen CryptoProviderName, der auf den ML-DSA-CNG-Anbieter verweist.
• Um ML-DSA zu unterstützen, müssen Zertifikatvorlagen zwei spezifische Änderungen vornehmen: einen nicht veralteten CNG-Schlüsselspeicheranbieter und die Einstellung des Zwecks auf Signatur, da ML-DSA nur Signieren, niemals Verschlüsselung unterstützt.
• AD CS unterstützt alle drei ML-DSA-Parametersätze im reinen Modus, über die CA-Hierarchieeinrichtung, die Ausstellung von Endzertifikaten und die OCSP-Antwortsignierung hinweg.
• Es gibt keinen direkten Upgrade-Pfad von einer bestehenden Zertifizierungsstelle; diese Bereitstellung erfordert die parallele Einrichtung neuer Stamm- und untergeordneter Zertifizierungsstellen, die vor jeder Produktionsmigration validiert werden müssen.

Voraussetzungen:

• Ein Domänencontroller, auf dem die neueste verfügbare Windows Server-Version läuft; Windows Server 2025 wird empfohlen.
• Zwei Server mit Windows Server 2025 und dem Sicherheitsupdate 2026-05 (KB5087539) oder höher: einer für die Stammzertifizierungsstelle, einer für die untergeordnete Zertifizierungsstelle.
• Für Registrierungstests: ein in die Domäne eingebundener Client unter Windows 11, Version 24H2 oder 25H2, mit dem Nicht-Sicherheitsupdate 2025-10 (KB5067036) oder höher.
• Mitgliedschaft in der Gruppe „Domänenadministratoren“ oder einer gleichwertigen Gruppe zur Verwaltung von Zertifikatvorlagen und der Installation der AD CS-Rolle.

Root-CA-Einrichtung

Die Stammzertifizierungsstelle kann über die Zertifizierungsstellenkonsole oder PowerShell konfiguriert werden. Die PowerShell-Konfiguration ist für reproduzierbare Test- und Pilotumgebungen zuverlässiger. Das folgende Beispiel verwendet ML-DSA-87 mit dem höchsten Parametersatz:

# KeyLength is specified in bits. For ML-DSA-87: 2592 bytes x 8 = 20736 bits

# For Standalone Root CA (recommended for production)
Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

# For Enterprise Root CA (lab and test environments)
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

Ersetzen Sie den Platzhalter durch den allgemeinen Namen Ihrer Stammzertifizierungsstelle. Für Produktionsumgebungen mit Offline-Bereitstellung wird eine eigenständige Stammzertifizierungsstelle empfohlen; eine Unternehmensstammzertifizierungsstelle eignet sich für Labor- und Testumgebungen, in denen die Stammzertifizierungsstelle in eine Domäne eingebunden ist. Beachten Sie den Wert für HashAlgorithm: NoHash, da die Signaturerstellung von ML-DSA im Gegensatz zur klassischen RSA- oder ECDSA-Zertifizierungsstellenkonfiguration keinen separaten Hash-Algorithmus-Parameter verwendet. Überprüfen Sie nach der Installation, ob das Stammzertifizierungsstellenzertifikat tatsächlich den ausgewählten ML-DSA-Algorithmus verwendet, indem Sie die Zertifizierungsstellenkonsole (certsrv.msc) öffnen und die Eigenschaften des Zertifizierungsstellenzertifikats prüfen.

Einrichtung untergeordneter CA

Die untergeordnete Zertifizierungsstelle folgt demselben Muster und wird von der oben eingerichteten ML-DSA-Root-Zertifizierungsstelle ausgestellt. Dadurch wird eine zweistufige PKI-Hierarchie vervollständigt, in der beide Stufen ML-DSA als Signaturalgorithmus verwenden. Vollständiger Schutz nach der Quantenzertifizierung setzt ML-DSA-Signaturen in der gesamten Zertifikatskette voraus – von der Root- über die untergeordneten bis hin zu den Blatt-Zertifizierungsstellen. Eine Hierarchie mit einer klassischen Root-Zertifizierungsstelle und einer ML-DSA-untergeordneten Zertifizierungsstelle bietet nicht den Schutz, den die Migration gewährleisten soll. Daher müssen beide Stufen gemeinsam als Teil derselben parallelen Hierarchie bereitgestellt werden.

Konfigurieren von Zertifikatvorlagen

Eine Zertifikatvorlage muss zwei spezifische Änderungen vornehmen, bevor sie ML-DSA unterstützt:

1. CNG-Anbieter: Legen Sie als Anbieter der Vorlage einen nicht veralteten kryptografischen Dienstanbieter fest, insbesondere einen Schlüsselspeicheranbieter. Post-Quanten-Algorithmen sind nur über CNG-Anbieter verfügbar, niemals über den veralteten CryptoAPI-Pfad.
2. Zweck der Unterschrift: Stellen Sie unter „Anforderungsbearbeitung“ den Zweck auf „Signatur“ ein. ML-DSA unterstützt ausschließlich Signaturvorgänge, niemals Verschlüsselung. Daher wird ML-DSA in Vorlagen, die noch für Verschlüsselung oder Schlüsselaustausch konfiguriert sind, nicht als Option angeboten.

Um CNG-Anbieter in der Vorlage auswählbar zu machen, müssen die Kompatibilitätseinstellungen für Zertifizierungsstelle und Zertifikatsempfänger mindestens auf Windows Server 2008 eingestellt sein. Einige integrierte Vorlagen sind standardmäßig auf „Signatur“ eingestellt. ML-DSA ist somit verfügbar, sobald der Schlüsselspeicheranbieter auf der Registerkarte „Kryptografie“ ausgewählt ist. Bei allen anderen Vorlagen muss der Zweck zunächst auf der Registerkarte „Anforderungsverarbeitung“ auf „Signatur“ geändert werden. Stellen Sie bei der Konfiguration von Erweiterungen sicher, dass die Anwendungsrichtlinien keine verschlüsselungsbezogenen OIDs wie „Verschlüsselndes Dateisystem“ oder „Sichere E-Mail“ enthalten und dass die Schlüsselverwendung keine Verschlüsselungsoptionen wie „Schlüsselaustausch nur mit Schlüsselverschlüsselung zulassen“ umfasst, da diese mit einem reinen Signaturalgorithmus in Konflikt stehen. Um eine ML-DSA-Codesignaturvorlage zu erstellen, duplizieren Sie eine vorhandene Codesignaturvorlage und übernehmen Sie die Änderungen für Anbieter und Zweck.

OCSP-Antwortsignierung konfigurieren

Die Widerrufsprüfung für ML-DSA-ausgestellte Zertifikate sollte selbst ML-DSA-signierte OCSP-Antworten verwenden, um einen vollständigen Ende-zu-Ende-Schutz nach der Quantenüberprüfung zu gewährleisten. Duplizieren Sie die integrierte OCSP-Antwortsignaturvorlage, legen Sie die Anbieterkategorie auf „Schlüsselspeicheranbieter“ und den Algorithmusnamen auf Ihren gewählten ML-DSA-Parametersatz fest (z. B. ML-DSA:65), erteilen Sie dem Computerkonto des Online Responders die Berechtigungen „Registrieren“ und „Automatische Registrierung“ und stellen Sie die Vorlage von der ML-DSA-konfigurierten untergeordneten Zertifizierungsstelle aus. Fügen Sie in der Verwaltungskonsole des Online Responders eine neue Widerrufskonfiguration hinzu, die auf das Zertifikat der ML-DSA-untergeordneten Zertifizierungsstelle verweist, um die Einrichtung abzuschließen.

Validierung und Monitoring

Bevor Sie ein Pilotprojekt als produktionsreif einstufen, validieren Sie die gesamte Zertifikatskette: Stellen Sie ein Testzertifikat von der untergeordneten ML-DSA-Zertifizierungsstelle aus und bestätigen Sie, dass der registrierende Client (Windows 11, 24H2 oder 25H2, mit KB5067036 oder höher) dieses erfolgreich anfordert, empfängt und validiert. Führen Sie dabei den tatsächlichen Registrierungsprozess durch und überprüfen Sie nicht nur die Zertifikate in der Konsole. Stellen Sie sicher, dass die OCSP-Antworten für dieses Zertifikat mithilfe der ML-DSA-Signaturkonfiguration korrekt validiert werden. Überwachen Sie zur fortlaufenden Überwachung das Ausstellungsvolumen von Zertifikaten und alle Registrierungsfehler speziell in der neuen Hierarchie, da ein Pilotprojekt mit paralleler Hierarchie eine eigene, von der Überwachung der Produktions-Zertifizierungsstelle getrennte Transparenz benötigt. Achten Sie außerdem auf Registrierungsversuche mit Legacy-CSP gegen reine ML-DSA-Vorlagen, da diese während der Übergangsphase als eindeutiges Fehlermuster auftreten.

Überlegungen zum Rollback

Da es sich hier um eine parallele Hierarchie und nicht um ein direktes Upgrade handelt, ist ein Rollback auf Infrastrukturebene strukturell einfach: Die Produktionsumgebung läuft während des gesamten Pilotprojekts unverändert auf der bestehenden klassischen Hierarchie weiter. Der entscheidende Punkt beim Rollback ist das Vertrauen von Clients und Anwendungen: Sobald Clients im Rahmen der Pilotphase dem neuen ML-DSA-Root vertrauen, erfordert das Entfernen dieses Vertrauens im Falle eines Abbruchs des Pilotprojekts dieselbe explizite Verwaltung des Truststores wie dessen Hinzufügung. Die Vertrauensverteilung im Pilotprojekt sollte auf eine definierte Testgruppe beschränkt bleiben, anstatt den neuen Root breit zu streuen, bis die Hierarchie vollständig validiert ist.

Was wir tatsächlich empfehlen würden

Beginnen Sie mit ML-DSA-65 für Labor- und Pilotprojekte, es sei denn, Ihre regulatorischen Anforderungen schreiben ML-DSA-87 (CNSA 2.0 oder vergleichbar) vor. ML-DSA-65 bietet einen geringeren Schlüssel- und Signaturaufwand bei gleichzeitig hoher Sicherheit. Erstellen Sie die vollständige Root-to-Subordinate-to-Leaf-Kette von Anfang an in ML-DSA, anstatt verschiedene Algorithmen zu mischen. Eine gemischte Hierarchie bietet keinen echten End-to-End-Schutz nach der Quantenbereinigung. Beschränken Sie die Vertrauensverteilung während der Pilotphase und validieren Sie den gesamten Registrierungs- und OCSP-Pfad mit realer Client-Hardware, bevor Sie die Anwendung über die Testgruppe hinaus erweitern.

Wie Verschlüsselungsberatung helfen kann

Die genaue Planung, welche Zertifikatvorlagen, Anwendungen und Legacy-CSP-Abhängigkeiten in Ihrer Umgebung in die neue ML-DSA-Hierarchie migriert werden müssen, ist die Inventarisierungsarbeit, für die CBOM Secure entwickelt wurde, um Ihren bestehenden Zertifikatsbestand und seine Anbieterkonfigurationen abzubilden, bevor die Pilotphase beginnt.

Unsere PQC-Beratungsdienste planen die parallele Hierarchiebereitstellung, den Pilotumfang und die Produktionsumstellungssequenz, die in diesem Leitfaden beschrieben werden, individuell angepasst an Ihre spezifische AD CS-Umgebung und Anwendungsabhängigkeiten. Für Organisationen, die die CA-Hierarchie verwalten lassen möchten, anstatt sie selbst zu betreiben, stellt CertSecure Manager ML-DSA-, Hybrid- und klassische Zertifikate für Microsoft AD CS und andere CA-Plattformen über eine zentrale Richtlinienebene aus und verwaltet diese.

Ein bekanntes Muster, mit echten Unterschieden

Der Aufbau einer ML-DSA-CA-Hierarchie in AD CS folgt dem zweistufigen Muster, das jedem PKI-Administrator bekannt ist: Stammzertifizierungsstelle, untergeordnete Zertifizierungsstelle, Vorlagen und OCSP. Die relevanten Unterschiede sind spezifisch und handhabbar, sobald man weiß, worauf man achten muss: Bitlänge des Schlüssels, ML-DSA-CNG-Providerstring, die Anforderung, dass die Zertifizierung ausschließlich für Signaturen verwendet werden darf, und die zwingende Voraussetzung, dass es sich um eine neue, parallele Hierarchie und nicht um eine Änderung an einer bestehenden Zertifizierungsstelle handeln muss. Eine korrekte und durchgängig validierte Pilotumgebung vor jeder Entscheidung über die Produktivumgebung macht aus einer Laborübung einen glaubwürdigen Migrationspfad.

Häufig gestellte Fragen

Welchen Wert für KeyLength muss ich für ML-DSA-87 in Install-AdcsCertificationAuthority verwenden?

20736 Bit, abgeleitet von der Schlüssellänge von 2,592 Byte gemäß ML-DSA-87 (2,592 Byte × 8 Bit pro Byte). Der Parameter „KeyLength“ wird stets in Bit und nicht in Byte angegeben, was häufig zu Konfigurationsfehlern führt.

Kann ich meine bestehende Produktions-CA auf ML-DSA aktualisieren, anstatt eine neue Hierarchie aufzubauen?

Nein. Ein Upgrade direkt vor Ort ist nicht möglich. Die Unterstützung von ML-DSA erfordert die Bereitstellung neuer Stamm- und untergeordneter Zertifizierungsstellen, die parallel zur Produktionsumgebung validiert und anschließend gezielt migriert werden.

Warum wird ML-DSA in meiner Zertifikatvorlage nicht als verfügbarer Algorithmus angezeigt?

Meist liegt es daran, dass die Vorlage noch einen veralteten kryptografischen Dienstanbieter anstelle eines CNG-Schlüsselspeicheranbieters verwendet oder dass der Zweck unter „Anforderungsverarbeitung“ nicht auf „Signatur“ eingestellt ist. Beide Änderungen sind erforderlich, bevor ML-DSA als auswählbarer Algorithmus angezeigt wird.

Unterstützt AD CS ML-DSA für die Signierung von OCSP-Antworten?

Ja. Durch die Konfiguration einer ML-DSA-signierten OCSP-Antwortsignaturvorlage, die von einer untergeordneten ML-DSA-Zertifizierungsstelle ausgestellt wurde, können Online-Responder eine durchgängige Überprüfung des postquantenbedingten Widerrufs von ML-DSA-ausgestellten Zertifikaten durchführen.

Welche Client-Version benötige ich zum Testen der ML-DSA-Zertifikatregistrierung?

Ein in eine Domäne eingebundener Windows 11-Client der Version 24H2 oder 25H2, auf dem das nicht sicherheitsrelevante Update 2025-10 (KB5067036) oder eine spätere Version installiert ist.