Beantragen von Zertifikaten mit auf ML-DSA basierenden Schlüsseln über den Registrierungsdienst für Netzwerkgeräte (NDES)

Autor Uwe GradeneggerVeröffentlicht am Kategorien Registrierungsdienst für Netzwerkgeräte (NDES), Zertifikat-BenutzungSchlagwörter , , , ,

Mit dem Mai 2026 Sicherheits-Update hat Microsoft die Unterstützung für den ML-DSA Algorithmus in den Active Directory Certificate Services bereitgestellt.

In ihrer Dokumentation schreiben sie zwar, dass NDES nicht mit ML-DSA kompatibel ist:

You can enroll ML-DSA certificates through the Certificates Microsoft Management Console (MMC) snap-in and certreq.exe. Enrollment through the Network Device Enrollment Service (NDES) isn’t currently available.

So ganz stimmt das aber nicht…

NDES ist wegen seiner Registration Authority-Zertifikate, die unbedingt einen Cryptographic Service Provider (CSP) benötigen, auf den RSA-Algorithmus eingeschränkt. Das heißt aber nicht, dass man keine modernen Algorithmen für die Beantragung von Zertifikaten über den NDES nutzen kann. Das hat schon bei Elliptischen Kurven oder AES für die innenliegende CMS-Nachricht funktioniert, warum also nicht auch per ML-DSA?

Die Testumgebung

Für die Testumgebung habe ich eine Zertifizierungsstellen-Hierarchie etabliert, die selbst ML-DSA-basierte Schlüssel verwendet. Damit der Prozess reproduzierbar ist, habe ich meine ADCS Deployment-Scripts um die Unterstützung von ML-DSA erweitert.

Den NDES-Server habe ich ohne Enterprise-Administrator-Rechte auf einem Windows Server 2025 mit Patchlevel von Mai 2026 installiert.

Damit ich SCEP-Zertifikatanforderungen mit ML-DSA erzeugen kann, habe ich das PSCertificateEnrollment PowerShell-Modul entsprechend erweitert.

Erkenntnisse

NDES-ZertifikatErkenntnis
Webserver-ZertifikatMuss von einer klassischen Hierarchie ausgestellt werden (RSA oder ECC). Der TLS-Stack in Windows scheint noch Probleme zu haben, wenn ein Zertifikat in der Kette ML-DSA nutzt.
NDES Enrollment AgentKann von einer reinen ML-DSA Hierarchie kommen, muss selbst aber einen RSA-Schlüssel nutzen wegen Einschränkung auf CSP. Muss von der gleichen Zertifizierungsstelle ausgestellt sein, die auch die Gerätezertifikate ausstellen wird.
NDES CEP EncryptionKann von einer reinen ML-DSA Hierarchie kommen, muss selbst aber einen RSA-Schlüssel nutzen wegen Einschränkung auf CSP. Muss von der gleichen Zertifizierungsstelle ausgestellt sein, die auch die Gerätezertifikate ausstellen wird.
NDES Geräte-ZertifikatKann komplett durch die gesamte Kette hindurch ML-DSA nutzen.

Das Ergebnis

Das Ergebnis ist dann fast schon unspektakulär – es funktioniert einfach. NDES ist der übertragene Inhalt effektiv egal wie es scheint.

$otp = Get-NDESOTP -ComputerName "ndes01.intra.pqclabor.de"
Get-SCEPCertificate `
  -ComputerName "ndes01.intra.pqclabor.de" `
  -ChallengePassword $otp `
  -Subject "CN=test" `
  -KeyAlgorithm ML-DSA:44

Zur Sinnhaftigkeit

Auch wenn es funktioniert stellt sich die Frage nach der Sinnhaftigkeit.

  • Kein Mobile Device Management (MDM)-Hersteller dieser Welt hat derzeit eine Implementierung für Postquanten-Kryptoalgorithmen, um diese dann mit SCEP zu nutzen.
  • Microsoft selbst sagt aus, dass die diese Kombination nicht unterstützen.
  • Die ganze PQC-Implementierung in Windows scheint noch nicht Produktionsreif zu sein. Beispielsweise wurde sie im Juli 2026 Patch gleich wieder kaputtgemacht.

Die Übung hat dennoch ihren Zweck erreicht. So kann ermittelt werden, was mit PQC bereits realisierbar ist und was nicht. Und so interpretiere ich den derzeitigen Stand der Implementierung in Windows: Als ein frühes Testfeld, um Erfahrungen zu gewinnen und sich auf den produktiven Einsatz vorzubereiten.

Eine Sache noch

Natürlich wird das TameMyCerts Policy Modul für die Active Directory Certificate Services in der nächsten Version auch ML-DSA unterstützen, sodass es wie gewohnt mit NDES und anderen Use Cases kombiniert werden kann.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish fr_FRFrançais de_DEDeutsch