Hur man bygger en ML-DSA CA-hierarki i Microsoft AD CS

Snabbt svar: Att bygga en ML-DSA-certifieringsutfärdarhierarki i AD CS på Windows Server 2025 följer samma tvåskiktade rot- och underordnade mönster som alla klassiska PKI, med tre verkliga skillnader: KeyLength-parametern anges i bitar härledda från algoritmens faktiska nyckelstorlek (20 736 bitar för ML-DSA-87), CryptoProviderName måste referera till ML-DSA CNG-leverantören explicit, och det finns ingen uppgraderingsväg på plats, så detta måste vara en ny hierarki som skapas parallellt med produktionen, inte en modifiering av en befintlig certifikatutfärdare. Du behöver två servrar som kör Windows Server 2025 med säkerhetsuppdateringen från maj 2026 (KB5087539) eller senare, en för roten och en för den underordnade certifikatutfärdaren, plus en domänansluten Windows 11-klient med uppdateringen från oktober 2025 eller senare för registreringstestning. Den här guiden går igenom den faktiska konfigurationen: förutsättningar, konfiguration av rot- och underordnade certifikat, certifikatmallar, validering och vad som ska övervakas efter distribution.

Vår guide om ML-DSA-support för din Microsoft PKI täcker vad denna funktion innebär strategiskt. Den här guiden är den praktiska hjälpen: de faktiska kommandona och konfigurationsstegen för att upprätta en fungerande ML-DSA CA-hierarki i en labb- eller pilotmiljö.

Key Takeaways

• En ML-DSA CA-hierarki kräver Windows Server 2025 med säkerhetsuppdateringen från maj 2026 (KB5087539) eller senare på både rot- och underordnade CA-servrar.
• PowerShells Install-AdcsCertificationAuthority tar KeyLength i bitar, beräknat från ML-DSA-parameteruppsättningens faktiska nyckelstorlek och ett CryptoProviderName som refererar till ML-DSA CNG-providern.
• Certifikatmallar behöver två specifika ändringar för att stödja ML-DSA: en icke-äldre CNG Key Storage Provider och Syfte inställt på Signatur, eftersom ML-DSA endast stöder signering, aldrig kryptering.
• AD CS stöder alla tre ML-DSA-parameteruppsättningar i rent läge, över konfiguration av CA-hierarki, utfärdande av lövcertifikat och signering av OCSP-svar.
• Det finns ingen uppgraderingsväg på plats från en befintlig CA; denna distribution måste hantera nya rot- och underordnade CA:er parallellt, validerade före någon produktionsmigrering.

Förutsättningar

• En domänkontrollant som kör den senaste tillgängliga Windows Server-versionen; Windows Server 2025 rekommenderas.
• Två servrar som kör Windows Server 2025 med säkerhetsuppdateringen 2026-05 (KB5087539) eller senare: en för rot-CA:n, en för den underordnade CA:n.
• För registreringstestning: en domänansluten klient som kör Windows 11, version 24H2 eller 25H2, med den icke-säkerhetsrelaterade uppdateringen 2025-10 (KB5067036) eller senare.
• Medlemskap i Domänadministratörer eller motsvarande, för att hantera certifikatmallar och installation av AD CS-roller.

Inställning av rot-CA

Rot-CA:n kan konfigureras via certifikatutfärdarkonsolen eller PowerShell. PowerShell-sökvägen är mer tillförlitlig för reproducerbara lab- och pilotdistributioner. Exemplet nedan använder ML-DSA-87, den högsta parameteruppsättningen:

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

Ersätt platshållaren med din rot-CA:s vanliga namn. Fristående rot-CA är det rekommenderade mönstret för produktions- och offline-root-distributioner; Enterprise Root CA är lämplig för lab- och testmiljöer där roten är domänansluten. Observera HashAlgorithm-värdet: NoHash, eftersom ML-DSAs signeringskonstruktion inte använder en separat hashalgoritmparameter på samma sätt som klassisk RSA- eller ECDSA CA-konfiguration gör. Efter installationen, bekräfta att rot-CA-certifikatet faktiskt använder den valda ML-DSA-algoritmen genom att öppna certifieringsutfärdarkonsolen (certsrv.msc) och inspektera CA-certifikatets egenskaper.

Inställning av underordnad certifikatutfärdare

Den underordnade CA:n följer samma mönster, utfärdat från ML-DSA-roten som etablerats ovan, och kompletterar en tvånivås PKI-hierarki där båda nivåerna använder ML-DSA som signaturalgoritm. Fullständigt post-kvantumskydd är beroende av ML-DSA-signaturer över hela certifikatkedjan, från rot till underordnad till löv; en hierarki med en klassisk rot och en ML-DSA-underordnad ger inte det skydd som migreringen är avsedd att ge, så båda nivåerna måste distribueras tillsammans som en del av samma parallella hierarki.

Konfigurera certifikatmallar

En certifikatmall behöver två specifika ändringar innan den stöder ML-DSA:

1. CNG-leverantör: Ställ in mallens leverantör till en icke-äldre kryptografisk tjänsteleverantör, specifikt en nyckellagringsleverantör. Postkvantalgoritmer är endast tillgängliga via CNG-leverantörer, aldrig den äldre CryptoAPI-sökvägen.
2. Syfte med signaturen: Ange Syfte under Begäranhantering till Signatur. ML-DSA stöder endast signeringsåtgärder, aldrig kryptering, så alla mallar som fortfarande är konfigurerade för kryptering eller nyckelutbyte kommer inte att erbjuda ML-DSA som ett alternativ.

För att göra CNG-leverantörer valbara i mallen, ställ in både certifikatutfärdaren och certifikatmottagarens kompatibilitetsinställningar till minst Windows Server 2008. Flera inbyggda mallar har redan standardinställningen Syfte: Signatur, vilket innebär att ML-DSA blir tillgänglig genom att helt enkelt ställa in Nyckellagringsleverantören på fliken Kryptografi. För alla andra mallar, ändra först Syfte till Signatur på fliken Hantering av förfrågningar. När du konfigurerar tillägg, bekräfta att Programpolicyer inte inkluderar krypteringsrelaterade OID:er som Krypterar filsystem eller Säker e-post, och bekräfta att Nyckelanvändning inte inkluderar krypteringsalternativ som Tillåt endast nyckelutbyte med nyckelkryptering, eftersom båda kommer att komma i konflikt med en algoritm som endast är signaturbaserad. För att bygga en specifik ML-DSA-kodsigneringsmall, duplicera en befintlig kodsigneringsmall och tillämpa samma leverantörs- och syftesändringar.

Konfigurera OCSP-svarssignering

Återkallningskontroll för ML-DSA-utfärdade certifikat bör i sig använda ML-DSA-signerade OCSP-svar för fullständigt end-to-end-skydd efter kvantum. Duplicera den inbyggda OCSP-svarssigneringsmallen, ange Providerkategori till Key Storage Provider och Algoritmnamn till din valda ML-DSA-parameteruppsättning (till exempel ML-DSA:65), bevilja registrerings- och autoregistreringsbehörigheter till onlineresponderns datorkonto och utfärda mallen från den ML-DSA-konfigurerade underordnade certifikatutfärdaren. Lägg till en ny återkallningskonfiguration i onlineresponderns hanteringskonsol som pekar på den underordnade ML-DSA-certifikatutfärdarens certifikat för att slutföra installationen.

Validering och övervakning

Innan du behandlar en pilot som produktionsklar, validera hela kedjan: utfärda ett testbladscertifikat från den underordnade ML-DSA-CA:n och bekräfta att den registrerande klienten (Windows 11, 24H2 eller 25H2, med KB5067036 eller senare) begär, tar emot och validerar det, och utövar den faktiska registreringsvägen istället för att bara inspektera certifikat i konsolen. Bekräfta att OCSP-svar för det certifikatet valideras korrekt med hjälp av ML-DSA-signeringskonfigurationen. För kontinuerlig övervakning, spåra certifikatutgivningsvolymen och eventuella registreringsfel specifikt i den nya hierarkin, eftersom en parallell hierarkipilot behöver sin egen synlighet separat från produktions-CA-övervakning, och var uppmärksam på äldre CSP-baserade registreringsförsök mot ML-DSA-mallar, vilka kommer att dyka upp som ett distinkt felmönster under övergångsperioden.

Överväganden vid återställning

Eftersom detta är en parallell hierarki snarare än en uppgradering på plats, är rollback strukturellt enkelt på infrastrukturnivå: produktionen fortsätter att köras på den befintliga klassiska hierarkin under hela pilotprojektet, orörd. Den verkliga rollback-övervägandet är klient- och applikationsförtroende: när klienter börjar lita på den nya ML-DSA-roten som en del av pilottestningen, kräver det samma explicita hantering av förtroendelager som att lägga till det för att ta bort det på ett rent sätt om pilotprojektet behöver överges. Håll pilotprojektets förtroendedistribution begränsad till en definierad testpopulation snarare än att publicera den nya roten brett tills hierarkin är helt validerad.

Vad vi egentligen skulle rekommendera

Börja med ML-DSA-65 för lab- och pilotarbete om inte din regelmiljö specifikt kräver ML-DSA-87 (CNSA 2.0 eller liknande), eftersom det erbjuder ett mindre fotavtryck för nyckel och signaturer samtidigt som det ger starka säkerhetsmarginaler. Bygg hela rot-till-underordnad-till-löv-kedjan i ML-DSA från början istället för att blanda algoritmnivåer, eftersom en blandad hierarki inte ger ett genuint end-to-end-skydd efter kvantum. Kontrollera förtroendedistributionen noggrant under pilotfasen och validera den fullständiga registreringen och OCSP-sökvägen med verklig klienthårdvara innan du expanderar bortom en testpopulation.

Hur krypteringskonsulting kan hjälpa

Att planera exakt vilka certifikatmallar, applikationer och äldre CSP-beroenden i din miljö som behöver migreras till den nya ML-DSA-hierarkin är det inventeringsarbete som CBOM Secure är byggt för att stödja, och kartlägger din befintliga certifikattillgång och dess leverantörskonfigurationer innan pilotprojektet börjar.

Våra PQC-rådgivningstjänster planerar den parallella hierarkidistribution, pilotomfattning och produktionsövergångssekvensering som den här guiden går igenom, skräddarsydd för er specifika AD CS-miljö och applikationsberoenden. För organisationer som vill att CA-hierarkin ska hanteras snarare än att den ska drivas själv, utfärdar och hanterar CertSecure Manager ML-DSA-, hybrid- och klassiska certifikat över Microsoft AD CS och andra CA-plattformar från ett enda policyplan.

Ett välbekant mönster, med verkliga skillnader

Att upprätta en ML-DSA CA-hierarki i AD CS följer det tvåskiktsmönster som alla PKI-administratörer redan känner till: rot, underordnad, mallar, OCSP. De skillnader som är viktiga är specifika och hanterbara när du väl vet att du ska leta efter dem: bitlängdsnyckelstorlek, ML-DSA CNG-leverantörssträngen, kravet på endast signaturändamål och den hårda begränsningen att detta måste vara en ny, parallell hierarki snarare än en ändring på plats av en befintlig CA. Att få pilotmiljön rätt, validerad från början till slut innan något beslut om produktionsförtroende, är det som förvandlar detta från en labbövning till en trovärdig migreringsväg.

Vanliga frågor om partihandel med mat och dryck

Vilket KeyLength-värde använder jag för ML-DSA-87 i Install-AdcsCertificationAuthority?

20736 bitar, härlett från ML-DSA-87:s nyckelstorlek på 2 592 byte (2 592 byte gånger 8 bitar per byte). Parametern KeyLength anges alltid i bitar, inte byte, vilket är en vanlig källa till konfigurationsfel.

Kan jag uppgradera min befintliga produktions-CA till ML-DSA istället för att bygga en ny hierarki?

Nej. Det finns ingen uppgraderingsväg på plats. ML-DSA-stöd kräver att nya rot- och underordnade certifieringsutfärdare distribueras, valideras parallellt med produktion och sedan migreras till dem medvetet.

Varför visar inte min certifikatmall ML-DSA som en tillgänglig algoritm?

Vanligtvis beror det på att mallen fortfarande använder en äldre kryptografisk tjänsteleverantör istället för en CNG-nyckellagringsleverantör, eller att Syfte under Begäranhantering inte är inställt på Signatur. Båda ändringarna krävs innan ML-DSA visas som en valbar algoritm.

Har AD CS stöd för ML-DSA för OCSP-svarssignering?

Ja. Genom att konfigurera en ML-DSA-signerad OCSP-svarssigneringsmall, utfärdad från en underordnad ML-DSA-certifikatutfärdare, kan Online Responders tillhandahålla komplett kontroll efter kvantåterkallning av ML-DSA-utfärdade certifikat.

Vilken klientversion behöver jag för att testa ML-DSA-certifikatregistrering?

En domänansluten Windows 11-klient på version 24H2 eller 25H2, med den icke-säkerhetsrelaterade uppdateringen 2025-10 (KB5067036) eller senare installerad.