Hoe bouw je een ML-DSA CA-hiërarchie in Microsoft AD CS?

Kort antwoord: Het opzetten van een ML-DSA-certificeringsinstantiehiërarchie in AD CS op Windows Server 2025 volgt hetzelfde tweelaagse patroon met een root- en een ondergeschikte CA als elke klassieke PKI, met drie belangrijke verschillen: de parameter KeyLength wordt gespecificeerd in bits, afgeleid van de werkelijke sleutelgrootte van het algoritme (20,736 bits voor ML-DSA-87), de CryptoProviderName moet expliciet verwijzen naar de ML-DSA CNG-provider en er is geen mogelijkheid tot in-place upgrades. Dit betekent dat er een nieuwe hiërarchie parallel aan de productieomgeving moet worden opgezet, en dat het geen aanpassing is van een bestaande CA. U hebt twee servers nodig met Windows Server 2025 en de beveiligingsupdate van mei 2026 (KB5087539) of later, één voor de root-CA en één voor de ondergeschikte CA, plus een Windows 11-client die is toegevoegd aan het domein en de update van oktober 2025 of later heeft voor het testen van de inschrijving. Deze handleiding beschrijft de daadwerkelijke configuratie: vereisten, configuratie van root- en subcertificaten, certificaatsjablonen, validatie en wat er na de implementatie in de gaten gehouden moet worden.

Onze handleiding 'ML-DSA-ondersteuning voor uw Microsoft PKI' beschrijft wat deze mogelijkheid strategisch gezien betekent. Deze handleiding is de praktische handleiding: de daadwerkelijke commando's en configuratiestappen voor het opzetten van een werkende ML-DSA CA-hiërarchie in een lab- of pilotomgeving.

Key Takeaways

• Een ML-DSA CA-hiërarchie vereist Windows Server 2025 met de beveiligingsupdate van mei 2026 (KB5087539) of later op zowel de root- als de onderliggende CA-servers.
• De PowerShell-opdracht Install-AdcsCertificationAuthority vereist een sleutellengte in bits, berekend op basis van de werkelijke sleutelgrootte van de ML-DSA-parameterreeks, en een CryptoProviderName die verwijst naar de ML-DSA CNG-provider.
• Certificaatsjablonen vereisen twee specifieke wijzigingen om ML-DSA te ondersteunen: een niet-verouderde CNG-sleutelopslagprovider en het doel moet worden ingesteld op 'Handtekening', aangezien ML-DSA alleen ondertekening ondersteunt en nooit versleuteling.
• AD CS ondersteunt alle drie de ML-DSA-parameterreeksen in pure modus, voor het opzetten van de CA-hiërarchie, het uitgeven van bladcertificaten en het ondertekenen van OCSP-reacties.
• Er is geen mogelijkheid om een ​​bestaande CA direct te upgraden; bij deze implementatie moeten parallel nieuwe root- en ondergeschikte CA's worden opgezet en gevalideerd voordat er een migratie naar de productieomgeving plaatsvindt.

Voorwaarden

• Een domeincontroller met de meest recente beschikbare versie van Windows Server; Windows Server 2025 wordt aanbevolen.
• Twee servers met Windows Server 2025 en de beveiligingsupdate van mei 2026 (KB5087539) of later: één voor de root-CA en één voor de subordinate-CA.
• Voor het testen van de inschrijving: een client die is aangesloten op een domein en waarop Windows 11, versie 24H2 of 25H2, met de niet-beveiligingsupdate 2025-10 (KB5067036) of later is geïnstalleerd.
• Lidmaatschap van de groep Domeinbeheerders of een gelijkwaardige groep is vereist om certificaatsjablonen en de installatie van AD CS-rollen te beheren.

Root CA-configuratie

De root-CA kan worden geconfigureerd via de console van de certificeringsinstantie of via PowerShell. De PowerShell-methode is betrouwbaarder voor reproduceerbare test- en pilotimplementaties. Het onderstaande voorbeeld gebruikt ML-DSA-87, de hoogste parameterinstelling:

# 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"

Vervang de placeholder door de algemene naam van uw root-CA. Standalone Root CA is het aanbevolen patroon voor offline root-implementaties in productieomgevingen; Enterprise Root CA is geschikt voor lab- en testomgevingen waar de root is gekoppeld aan een domein. Let op de waarde van HashAlgorithm: NoHash, aangezien de ondertekeningsconstructie van ML-DSA geen aparte hash-algoritme-parameter gebruikt zoals de klassieke RSA- of ECDSA-CA-configuratie dat wel doet. Controleer na de installatie of het root-CA-certificaat daadwerkelijk het geselecteerde ML-DSA-algoritme gebruikt door de console van de certificeringsinstantie (certsrv.msc) te openen en de eigenschappen van het CA-certificaat te inspecteren.

Ondergeschikte CA-configuratie

De ondergeschikte CA volgt hetzelfde patroon en wordt uitgegeven vanuit de hierboven vastgestelde ML-DSA-root, waarmee een tweelaagse PKI-hiërarchie wordt voltooid waarbij beide lagen ML-DSA als ondertekeningsalgoritme gebruiken. Volledige bescherming na een quantumaanval is afhankelijk van ML-DSA-ondertekeningen in de gehele certificaatketen, van root via ondergeschikte tot leaf; een hiërarchie met een klassieke root en een ML-DSA-ondergeschikte biedt niet de bescherming die de migratie beoogt te leveren, dus moeten beide lagen samen worden geïmplementeerd als onderdeel van dezelfde parallelle hiërarchie.

Certificaatsjablonen configureren

Een certificaatsjabloon moet aan twee specifieke voorwaarden voldoen voordat het ML-DSA ondersteunt:

1. CNG-leverancier: Stel de provider van de template in op een niet-verouderde cryptografische serviceprovider, met name een sleutelopslagprovider. Post-kwantumalgoritmen zijn alleen beschikbaar via CNG-providers, nooit via het verouderde CryptoAPI-pad.
2. Doel van de handtekening: Stel het doel onder 'Verzoekafhandeling' in op 'Handtekening'. ML-DSA ondersteunt alleen ondertekeningsbewerkingen, nooit versleuteling. Daarom zal een sjabloon dat nog steeds is geconfigureerd voor versleuteling of sleuteluitwisseling ML-DSA niet als optie aanbieden.

Om CNG-providers überhaupt selecteerbaar te maken in de sjabloon, stelt u de compatibiliteitsinstellingen voor zowel de certificeringsinstantie als de certificaatontvanger in op minimaal Windows Server 2008. Verschillende ingebouwde sjablonen hebben standaard al het doel 'Handtekening', wat betekent dat ML-DSA beschikbaar komt door simpelweg de sleutelopslagprovider in te stellen op het tabblad Cryptografie; voor alle andere sjablonen moet u eerst het doel wijzigen naar 'Handtekening' op het tabblad Aanvraagverwerking. Controleer bij het configureren van extensies of het toepassingsbeleid geen encryptiegerelateerde OID's bevat, zoals 'Bestandssysteem versleutelen' of 'Beveiligde e-mail', en controleer of 'Sleutelgebruik' geen encryptieopties bevat zoals 'Alleen sleuteluitwisseling toestaan ​​met sleutelversleuteling', aangezien beide conflicteren met een algoritme dat alleen handtekeningen gebruikt. Om specifiek een ML-DSA-codeondertekeningssjabloon te maken, dupliceert u een bestaande codeondertekeningssjabloon en past u dezelfde wijzigingen in provider en doel toe.

OCSP-antwoordondertekening configureren

De intrekkingscontrole voor door ML-DSA uitgegeven certificaten moet zelf gebruikmaken van door ML-DSA ondertekende OCSP-reacties voor volledige end-to-end bescherming na de kwantumfase. Dupliceer de ingebouwde OCSP-reactieondertekeningssjabloon, stel de providercategorie in op 'Key Storage Provider' en de algoritmenaam op de door u gekozen ML-DSA-parameterset (bijvoorbeeld ML-DSA:65), verleen de machtigingen 'Inschrijven' en 'Automatisch inschrijven' aan het computeraccount van de online responder en geef de sjabloon uit vanuit de voor ML-DSA geconfigureerde ondergeschikte CA. Voeg een nieuwe intrekkingsconfiguratie toe in de beheerconsole van de online responder die verwijst naar het certificaat van de voor ML-DSA geconfigureerde ondergeschikte CA om de configuratie te voltooien.

Validatie en monitoring

Voordat een pilot als productieklaar wordt beschouwd, moet de volledige certificaatketen worden gevalideerd: geef een testcertificaat uit van de ML-DSA-ondergeschikte CA en controleer of de inschrijvende client (Windows 11, 24H2 of 25H2, met KB5067036 of later) het certificaat succesvol aanvraagt, ontvangt en valideert. Hierbij wordt het daadwerkelijke inschrijfproces doorlopen in plaats van alleen certificaten in de console te controleren. Controleer of de OCSP-reacties voor dat certificaat correct worden gevalideerd met behulp van de ML-DSA-ondertekeningsconfiguratie. Voor continue monitoring moet het volume van certificaatuitgiften en eventuele inschrijffouten specifiek voor de nieuwe hiërarchie worden bijgehouden, aangezien een pilot met een parallelle hiërarchie een eigen zichtbaarheid vereist, los van de monitoring van de productie-CA. Let ook op inschrijfpogingen via de legacy CSP tegen ML-DSA-only templates, die zich tijdens de overgangsperiode als een afzonderlijk foutpatroon zullen manifesteren.

Overwegingen met betrekking tot terugdraaien

Omdat dit een parallelle hiërarchie betreft in plaats van een in-place upgrade, is terugdraaien structureel eenvoudig op infrastructuurniveau: de productieomgeving blijft tijdens de pilot onaangeraakt op de bestaande klassieke hiërarchie draaien. De belangrijkste overweging bij terugdraaien is het vertrouwen van clients en applicaties: zodra clients de nieuwe ML-DSA-root vertrouwen als onderdeel van de pilottests, vereist het op een nette manier verwijderen van dat vertrouwen, mocht de pilot moeten worden stopgezet, hetzelfde expliciete beheer van de vertrouwensopslag als bij het toevoegen ervan. Beperk de vertrouwensdistributie van de pilot tot een gedefinieerde testpopulatie in plaats van de nieuwe root breed uit te rollen totdat de hiërarchie volledig is gevalideerd.

Wat we daadwerkelijk zouden aanbevelen

Begin met ML-DSA-65 voor lab- en pilotprojecten, tenzij uw regelgeving specifiek ML-DSA-87 (CNSA 2.0 of vergelijkbaar) vereist, aangezien deze een kleinere sleutel- en handtekeningvoetafdruk biedt met behoud van sterke beveiligingsmarges. Bouw de volledige keten van root-naar-ondergeschikte-naar-leaf in ML-DSA vanaf het begin op in plaats van algoritmeniveaus te combineren, aangezien een gemengde hiërarchie geen echte end-to-end bescherming na een kwantumaanval biedt. Beperk de vertrouwensverdeling nauwkeurig tijdens de pilotfase en valideer het volledige registratie- en OCSP-pad met echte clienthardware voordat u de implementatie uitbreidt buiten een testpopulatie.

Hoe encryptieconsultancy kan helpen

Het nauwkeurig plannen van welke certificaatsjablonen, applicaties en bestaande CSP-afhankelijkheden in uw omgeving moeten worden gemigreerd naar de nieuwe ML-DSA-hiërarchie, is de inventarisatietaak die CBOM Secure ondersteunt. Hiermee wordt uw bestaande certificaatportfolio en de bijbehorende providerconfiguraties in kaart gebracht voordat de pilot van start gaat.

Onze PQC Advisory Services plannen de implementatie van de parallelle hiërarchie, de reikwijdte van de pilot en de overgang naar productie, zoals beschreven in deze handleiding, afgestemd op uw specifieke AD CS-omgeving en applicatieafhankelijkheden. Voor organisaties die de CA-hiërarchie liever zelf beheren dan zelf uitvoeren, biedt CertSecure Manager de mogelijkheid om ML-DSA-, hybride en klassieke certificaten uit te geven en te beheren voor Microsoft AD CS en andere CA-platformen vanuit één centraal beleidsvlak.

Een bekend patroon, met echte verschillen.

Het opzetten van een ML-DSA CA-hiërarchie in AD CS volgt het tweelaagse patroon dat elke PKI-beheerder al kent: root, ondergeschikt, templates, OCSP. De belangrijke verschillen zijn specifiek en beheersbaar zodra je weet waar je op moet letten: de sleutelgrootte in bits, de ML-DSA CNG-providerstring, de vereiste dat het alleen voor ondertekening bedoeld is, en de strikte voorwaarde dat dit een nieuwe, parallelle hiërarchie moet zijn en geen wijziging van een bestaande CA. Het correct opzetten van de pilotomgeving, die van begin tot eind gevalideerd is voordat er een vertrouwensbeslissing voor de productieomgeving wordt genomen, maakt van dit een geloofwaardig migratietraject in plaats van een laboefening.

Veelgestelde Vragen / FAQ

Welke KeyLength-waarde moet ik gebruiken voor ML-DSA-87 in Install-AdcsCertificationAuthority?

20736 bits, afgeleid van de sleutelgrootte van 2,592 bytes van ML-DSA-87 (2,592 bytes maal 8 bits per byte). De parameter KeyLength wordt altijd in bits gespecificeerd, niet in bytes, wat een veelvoorkomende bron van configuratiefouten is.

Kan ik mijn bestaande productie-CA upgraden naar ML-DSA in plaats van een nieuwe hiërarchie op te bouwen?

Nee. Er is geen upgrade-mogelijkheid die direct kan worden uitgevoerd. ML-DSA-ondersteuning vereist de implementatie van nieuwe root- en onderliggende certificeringsinstanties, die parallel aan de productieomgeving worden gevalideerd en vervolgens doelgericht worden gemigreerd.

Waarom wordt ML-DSA niet als beschikbaar algoritme weergegeven in mijn certificaatsjabloon?

Meestal komt dit doordat de sjabloon nog steeds een verouderde cryptografische serviceprovider gebruikt in plaats van een CNG-sleutelopslagprovider, of omdat het doel onder 'Verzoekafhandeling' niet is ingesteld op 'Handtekening'. Beide wijzigingen zijn vereist voordat ML-DSA als selecteerbaar algoritme verschijnt.

Ondersteunt AD CS ML-DSA voor het ondertekenen van OCSP-reacties?

Ja. Door een ML-DSA-ondertekende OCSP-antwoordondertekeningssjabloon te configureren, uitgegeven door een ML-DSA-ondergeschikte CA, kunnen online responders end-to-end controles uitvoeren op intrekking van ML-DSA-certificaten na het verstrijken van de quantumlimiet.

Welke clientversie heb ik nodig om de ML-DSA-certificaatregistratie te testen?

Een Windows 11-client met versie 24H2 of 25H2 die is aangesloten op een domein, en waarop de niet-beveiligingsupdate 2025-10 (KB5067036) of later is geïnstalleerd.