Meteen naar de inhoud

Certificaten voor 47 dagen komen eraan. Ben je er klaar voor?

Handel nu →

Post-kwantumcryptografie doet zijn intrede in AD CS: wat ML-DSA-ondersteuning werkelijk betekent voor uw Microsoft PKI.

PQC

Key Takeaways

  • De beveiligingsupdate van mei 2026 (KB5087539) introduceert ML-DSA (het NIST). FIPS204 (post-quantum signature algorithm) naar AD CS op Windows Server 2025. CA's, certificaatsjablonen en Online Responders kunnen nu ondertekenen met quantumresistente sleutels.
  • ML-DSA Het is uitsluitend gebaseerd op handtekeningen. Het beschermt tegen toekomstige vervalsing van certificaten en codehandtekeningen; het maakt TLS-sessies of versleutelde gegevens niet kwantumveilig. Daarvoor is ML-KEM nodig, dat Microsoft samen met samengestelde certificaten voor een latere fase heeft gepland.
  • Er is geen migratie ter plaatse mogelijk. Bestaande CA's kunnen niet worden omgezet naar ML-DSA: er moet een nieuwe, parallelle hiërarchie worden opgezet. Dat maakt het voorbereidende werk goedkoop en uitstel duur.
  • De regelgevende termijn staat vast, ook al is de kwantumtermijn dat niet: NIST is van plan RSA-2048 en ECDSA P-256 na 2030 uit te faseren en alle kwantumkwetsbare publieke-sleutelalgoritmen na 2035 te verbieden. Vertrouwensankers die vandaag zijn uitgegeven, overlappen deze data al.
  • De praktische eerste stap is geen algoritme-wissel: het is een cryptografische inventarisatie en een automatiseringslaag die de uiteindelijke wissel tot een configuratiewijziging maakt in plaats van een project dat meerdere jaren in beslag neemt.

Een stille update met grote gevolgen.

Op 12 mei 2026 bracht Microsoft een van de meest ingrijpende wijzigingen in de meer dan twintigjarige geschiedenis van Active Directory Certificate Services uit. De beveiligingsupdate 2026-05 voor Windows Server 2025 (KB5087539) stelt AD CS in staat om certificeringsinstanties te bouwen, certificaten uit te geven en OCSP-reacties te ondertekenen met behulp van ML-DSA, het op module-lattice gebaseerde digitale handtekeningalgoritme dat door NIST is gestandaardiseerd in FIPS 204. Het is het eerste post-kwantumalgoritme dat algemeen beschikbaar is gekomen binnen de ingebouwde CA van Microsoft.

Dat is van belang, niet alleen vanwege de cryptografie. Active Directory Certificate System (AD CS) vormt de stille basis voor certificaatuitgifte in een zeer groot deel van de Windows-omgevingen van bedrijven wereldwijd: domeinauthenticatie, smartcards, apparaatregistratie, interne TLS en codeondertekening . Jarenlang was de gangbare opvatting dat AD CS in onderhoudsmodus verkeerde en dat serieuze cryptografische modernisering elders zou moeten plaatsvinden. De releasecyclus van 2025-2026 (CRL-partitionering, verbeteringen in audits en nu PQC) draait dat verhaal om. De boodschap van Microsoft is ondubbelzinnig: de ingebouwde CA is een deelnemer aan de post-kwantumtransitie, geen slachtoffer ervan.

In deze blog bespreken we wat er is geleverd, de cryptografie erachter, wat vandaag de dag wel en niet werkt, de wettelijke deadlines die dit alles bepalen, en een pragmatisch, gefaseerd tijdschema waarmee uw PKI-team kan plannen.

Waarom post-kwantumcryptografie nodig is en waarom PKI de eerste in lijn is.

Elk certificaat dat uw certificeringsinstantie (CA) tegenwoordig uitgeeft, is gebaseerd op RSA of elliptische-curve-wiskunde. Beide ontlenen hun veiligheid aan problemen (integerfactorisatie en discrete logaritmen) die een voldoende grote, fouttolerante kwantumcomputer met het algoritme van Shor efficiënt zou kunnen oplossen. Symmetrische cryptografie doet het veel beter: het algoritme van Grover halveert slechts de effectieve sleutelsterkte, waardoor AES-256 en SHA-2 ruimschoots veilig blijven. Het existentiële probleem concentreert zich precies op het gebied waar PKI zich bevindt: asymmetrische sleutels en digitale handtekeningen.

Niemand kan voorspellen in welk jaar een cryptografisch relevante kwantumcomputer zijn intrede zal doen. Maar het risico is nu al aanwezig, om twee verschillende redenen:

  • Nu oogsten, later ontcijferen. Tegenstanders registreren momenteel versleuteld verkeer en gestolen codetekst met de bedoeling deze te decoderen zodra kwantumtechnologie voldoende ontwikkeld is. Alle gegevens waarvan de vertrouwelijkheid de kwantumhorizon moet overleven (medische dossiers, intellectueel eigendom, staatsgeheimen) worden in feite blootgesteld zodra ze een kwantumkwetsbare sleuteluitwisseling passeren.
  • Een langdurig vertrouwen. Dit is een PKI-specifiek probleem, en het gaat om handtekeningen in plaats van geheimhouding. Een root-CA-certificaat dat in 2026 is uitgegeven met een geldigheidsperiode van vijftien of twintig jaar, moet tot 2041 of langer onvervalsbaar blijven. Een code-ondertekening of firmware-handtekening die vandaag wordt toegepast, zal pas over jaren door de vertrouwende partijen worden geverifieerd. Als het onderliggende algoritme binnen die periode valt, kan een aanvaller frauduleuze certificaten en vervalste updates creëren die perfect aansluiten op uw vertrouwensankers: waardoor alles wat daarop is gebouwd, achteraf wordt besmet.

Als je de berekeningen maakt, is de urgentie niet langer theoretisch. Vertrouwensankers zijn de meest duurzame cryptografische artefacten in elke organisatie. Een klassieke basis die vandaag de dag wordt gecreëerd, is de gok dat kwantumcomputers de komende twintig jaar niet volwassen zullen worden, een gok die NIST, de NSA en Microsoft allemaal publiekelijk hebben afgewezen.

De normen achter de verschuiving

In augustus 2024, na een acht jaar durende wereldwijde competitie, finaliseerde NIST zijn eerste drie post-kwantumstandaarden. Alle drie zijn gebaseerd op wiskundige problemen (voornamelijk gestructureerde roosters) waarvoor geen efficiënt kwantumalgoritme bekend is:

StandaardAlgoritme (afstamming)DoelStatus in Windows
FIPS204ML-DSA (KRISTALLEN-Dilithium)Digitale handtekeningenGA, en nu live in AD CS
FIPS203ML-KEM (CRYSTALS-Kyber)Sleutelversleuteling / sleuteluitwisselingAlgemene beschikbaarheid in CNG API's; AD CS-ondersteuning gepland (fase 2)
FIPS205SLH-DSA (SPHINCS+)Staatloze hash-gebaseerde handtekeningenBeschikbaar in de cryptografische bibliotheken van Microsoft; geen AD CS-algoritme meer.

Een vierde ondertekeningsstandaard, FN-DSA (gebaseerd op Falcon), bevindt zich nog in de ontwerpfase. Voor PKI-planning binnen bedrijven is de belangrijkste combinatie eenvoudig: ML-DSA vervangt RSA/ECDSA voor ondertekening; ML-KEM vervangt RSA-encryptie en (EC)DH voor sleuteluitwisseling. AD CS Fase 1 levert de eerste helft van die combinatie.

De klok waar je daadwerkelijk tegen racet

Het eerlijke antwoord op de vraag "wanneer zullen kwantumcomputers RSA kraken?" is dat niemand het weet. Het antwoord vanuit het oogpunt van compliance is veel concreter, omdat toezichthouders hebben besloten niet op zekerheid te wachten. Drie tijdlijnen komen nu samen in hetzelfde decennium:

DatumMilestone
augustus 2024NIST rondt FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en af. FIPS205 (SLH-DSA).
november 2024NIST IR 8547 (concept), Overgang naar post-kwantumcryptografiestandaarden, publiceert het stappenplan voor de uitfasering van RSA. ECDSA, ECDH, DSA en eindige-veld DH.
2025Microsoft kondigt zijn Quantum Safe Program aan en levert PQC-algoritmen via SymCrypt en de CNG API's aan Windows Insiders; Linux-ondersteuning volgt via SymCrypt-OpenSSL.
Okt-nov 2025PQC is vanaf nu algemeen beschikbaar in Windows Server 2025, Windows 11 24H2/25H2 (clientondersteuning via KB5067036) en .NET 10.
May 12, 2026 AD CS ML-DSA-ondersteuning GA op Windows Server 2025 via beveiligingsupdate KB5087539.
2027NSA CNSA 2.0Nieuwe aankopen voor de Amerikaanse nationale veiligheidssystemen moeten kwantumresistente algoritmen ondersteunen.
2029Het uitgesproken doel van Microsoft is om PQC zo snel mogelijk in al haar eigen producten en diensten te implementeren.
2030NIST IR 8547: algoritmen op het 112-bits beveiligingsniveau (RSA-2048 en ECDSA P-256) zijn verouderd. Voortgezet gebruik vereist een gedocumenteerde risicoacceptatie.
2033Microsoft streeft ernaar de overstap naar PQC twee jaar vóór de federale deadline af te ronden.
2035NIST IR 8547 / NSM-10: alle kwantumkwetsbare publieke-sleutelalgoritmen (RSA met elke sleutelgrootte, ECDSA, ECDH, DSA, FFDH) zijn niet toegestaan. Er is geen mogelijkheid meer om risico's te accepteren.

Voeg nu uw eigen certificaatlevensduren toe aan die tabel. Een rootcertificaat met een geldigheidsduur van 20 jaar, uitgegeven in 2026, verloopt in 2046, elf jaar na de datum waarop het certificaat niet meer geldig is. Een uitgevende CA met een geldigheidsduur van 10 jaar, die volgend jaar wordt aangemaakt, is nog steeds operationeel wanneer RSA-2048 een gedocumenteerde auditbevinding wordt. Dit is de reden waarom Microsoft eerst ondersteuning aan de CA-kant heeft uitgebracht: de objecten met de langste levensduur in de hiërarchie zijn de objecten die het eerst moeten worden verplaatst.

Wat Microsoft daadwerkelijk heeft uitgebracht in AD CS

Fase 1 is bewust afgebakend: het omvat het volledige ondertekeningsvlak van een Microsoft PKI . Concreet kan AD CS op een gepatchte Windows Server 2025-machine nu het volgende:

  • Installeer root-, ondergeschikte-, bedrijfs- en zelfstandige CA's waarvan de eigen sleutelpaar- en certificaatondertekeningsprocessen gebruikmaken van ML-DSA, inclusief een volledig post-quantum keten wanneer elke laag dit gebruikt.
  • Publiceer certificaatsjablonen die ML-DSA-bladcertificaten uitgeven voor codeondertekening, TLS/webservers, gebruikers en computers.
  • Registreer die certificaten via de MMC-module Certificaten en certreq.exe, inclusief de evaluatie van ACL-sjablonen in de stijl van automatische registratie.
  • Ondertekenen OCSP reacties met een ML-DSA Online Responder-ondertekeningscertificaat.
  • Authenticode-codehandtekeningen verifiëren en toepassen met ML-DSA-certificaten: Set-AuthenticodeSignature en de gebruikersinterface voor handtekeningen werken naadloos samen, en .NET 10 stelt het algoritme beschikbaar aan ontwikkelaars via de klassen MLDsa/MLDsaCng.

Microsoft heeft de roadmap voor de toekomst expliciet gepubliceerd. Ondersteuning wordt gefaseerd uitgerold en het platformteam heeft zich ertoe verbonden PQC uit te breiden naar alle AD CS-rolservices: de Certificate Enrollment Policy en Enrollment Web Services (CEP/CES), NDES en de Online Responder.

BekwaamheidStandaardDoelAD CS-status
ML-DSA (zuiver)FIPS204PQ digitale handtekeningenNu beschikbaar (Fase 1)
ML-KEMFIPS203PQ-sleutelinkapselingGepland (Fase 2)
Samengestelde ML-DSAIETF LAMPS-ontwerpKlassieke handtekening + PQ-handtekening in één certificaatGepland (Fase 2)
Samengestelde ML-KEMIETF LAMPS-ontwerpKlassieke + PQ-sleutelinkapselingGepland (Fase 2)
CEP / CES / NDES / OCSP rol-service dekkingNBPQ-inschrijving en -intrekking loodgieterswerkToegewijd; geleidelijk aan arriverend

Platformbasislijn. PQC in AD CS vereist Windows Server 2025 met de beveiligingsupdate van mei 2026 (KB5087539) of later op de CA, en Windows 11 24H2/25H2 met de update van oktober 2025 (KB5067036) of later op de clients die zich inschrijven. Er zijn geen aanwijzingen voor een backport: Windows Server 2019 en 2022 CA's zullen naar verwachting geen PQC-ondersteuning krijgen. Als uw uitgevende CA's nog steeds op oudere platforms draaien, is de OS-upgrade nu officieel onderdeel van het kritieke pad voor PQC. Alle PQC-algoritmen vereisen ook CNG Key Storage Providers: oudere CryptoAPI CSP's worden niet ondersteund.

ML-DSA onder de motorkap: wat PKI-engineers moeten weten

ML-DSA stamt af van CRYSTALS-Dilithium, de belangrijkste winnaar van de NIST-competitie. De beveiliging ervan berust op de moeilijkheid van de problemen Module Learning With Errors en Module Short Integer Solution over gestructureerde roosters, wiskunde waarvoor geen efficiënte kwantumaanval bekend is. Twee van de eigenschappen ervan bepalen direct hoe AD CS zich gedraagt, dus het is de moeite waard om deze te begrijpen voordat u een console aanraakt.

Het is een algoritme dat alleen op handtekeningen gebaseerd is.

ML-DSA kan geen gegevens versleutelen en kan geen sleuteluitwisseling uitvoeren. Dat ene feit verklaart de meeste configuratiebeperkingen waar u tegenaan loopt: sjablonen moeten voor ondertekeningsdoeleinden zijn, het gebruik van sleutels voor sleutelversleuteling en sleutelovereenkomst is verboden, EFS- en beveiligde e-mail-EKU's worden geweigerd en de vertrouwelijkheid van TLS- sessies blijft intact totdat ML-KEM beschikbaar komt. Als een workflow een sleutel nodig heeft om gegevens te beschermen in plaats van om identiteit of integriteit te bewijzen , is ML-DSA per definitie het verkeerde hulpmiddel.

Drie parameterreeksen, drie afwegingen tussen beveiliging en omvang.

AD CS ondersteunt alle drie de FIPS 204-parameterreeksen in pure (niet-samengestelde) modus. Kies de gewenste beveiligingscategorie en het budget dat u beschikbaar hebt:

ParametersetNIST-categoriePublieke sleutelPrivésleutelSignature"Toetsgrootte" weergegeven in de Windows-interface
ML-DSA-44Niveau 21,312 B2,560 B2,420 B10,496 beetjes
ML-DSA-65Niveau 31,952 B4,032 B3,309 B15,616 beetjes
ML-DSA-87Niveau 52,592 B4,896 B4,627 B20,736 beetjes

Een detail dat mensen bij de eerste kennismaking in verwarring brengt: de Windows-interface geeft sleutelgroottes weer zoals 15,616 bits, wat vreemd lijkt naast RSA-2048. Het is simpelweg de lengte van de publieke sleutel uitgedrukt in bits (1,952 bytes × 8). Niets exotisch: gewoon een veel grotere sleutel. Als richtlijn geldt dat ML-DSA-65 de verstandige standaard is voor het uitgeven van CA's en bladcertificaten (categorie 3 is vergelijkbaar met AES-192), ML-DSA-87 is geschikt voor rootcertificaten en langlevende ankers waar maximale marge gewenst is, en ML-DSA-44 is voor gevallen met een zeer beperkte grootte waar categorie 2 een gangbare praktijk is.

Waarom het keuzemenu voor het hash-algoritme verdwijnt

Klassieke PKI is gebaseerd op hash-then-sign: de CA berekent een hash van de te ondertekenen gegevens en ondertekent deze vervolgens met zijn privésleutel. De keuze van de hash was een aparte, configureerbare vrijheidsgraad, wat er uiteindelijk toe leidde dat MD5 en SHA-1 werden ondertekend met perfect geldige sleutels, waarna er pijnlijke migraties nodig waren om dit te corrigeren. ML-DSA verwijdert deze mogelijkheid: de berichtverwerking is een integraal onderdeel van het ondertekeningsschema zelf, intern vastgelegd en niet door de operator te selecteren.

AD CS maakt dit eerlijk duidelijk. Zodra je tijdens de CA-configuratie een ML-DSA-sleutelalgoritme selecteert, wordt de lijst met hash-algoritmen teruggebracht tot één enkele optie: NoHash. Op certificaatsjablonen worden de hash-selector en de optie 'alternatieve handtekeningindeling' (de PKCS#1 v2.1-schakelaar) grijs weergegeven: er is geen variant van het handtekeningschema om uit te kiezen. NoHash betekent niet dat de gegevens niet gehasht zijn; het betekent dat de hashing is ingebouwd in FIPS 204 en dat AD CS niet zal doen alsof je een keuze hebt. Een hele categorie historische PKI-configuratiefouten houdt hiermee simpelweg op te bestaan.

Zuivere versus samengestelde certificaten: de transitievraag.

Certificaten na de kwantumcrisis zijn er in twee architectuurvarianten, en Microsoft heeft bewust beide in zijn roadmap opgenomen:

  • Pure. Het certificaat maakt gebruik van één enkel post-quantumalgoritme: wat AD CS momenteel levert. Het is de meest efficiënte eindtoestand, maar elke partij in de keten die erop vertrouwt, moet ML-DSA al begrijpen om het te kunnen valideren. In een heterogene omgeving vol apparaten, embedded stacks en verouderde middleware is dat een aanzienlijke beperking.
  • Composiet. Het certificaat bevat een klassieke sleutel (RSA of ECDSA) en een post-kwantumsleutel, en de handtekening bevat beide. Validatie vereist beide, dus vervalsing betekent het kraken van beide algoritmes. Het certificaat blijft veilig zolang een van beide geldig is. De prijs hiervoor is de omvang (je hebt van alles twee exemplaren) en de vereiste dat validators het samengestelde formaat begrijpen, zoals momenteel gedefinieerd in IETF LAMPS-concepten.

Praktische informatie: pure ML-DSA is geschikt voor gesloten, nieuwe ecosystemen waar u elke validator beheert: interne codeondertekening, infrastructuurattestatie en machine-to-machine-vertrouwen binnen een beheerde vloot. Composite is het migratiemiddel voor gemengde omgevingen, waar u bescherming na een quantumaanval nodig hebt zonder dat de werking ervan afhangt van universele ML-DSA-ondersteuning vanaf dag één. AD CS Fase 2 zal naar verwachting composite ML-DSA en composite ML-KEM introduceren ; tot die tijd kunt u het beste pure implementaties plannen rondom compatibiliteitstesten met de vertrouwende partijen.

Adviesdiensten op maat

Wij beoordelen, ontwikkelen strategieën en implementeren encryptiestrategieën en -oplossingen die zijn afgestemd op uw behoeften.

Een ML-DSA CA opzetten: wat werkt vandaag de dag?

Uitsluitend nieuwe hiërarchieën, en dat is zo bedoeld.

Het allerbelangrijkste implementatiefeit: ML-DSA CA's moeten volledig nieuw geïnstalleerd worden. Er is geen mogelijkheid om een ​​bestaande CA ter plekke te converteren, en er is geen optie om te vernieuwen met een nieuw algoritme: het wijzigen van het publieke-sleutelalgoritme betekent een nieuwe sleutel, een nieuw certificaat en in feite een nieuwe CA-identiteit. Microsoft adviseert om een ​​parallelle post-quantum hiërarchie naast uw productie-PKI op te bouwen en workloads geleidelijk te migreren. Hoewel dit misschien onhandig klinkt, weerspiegelt het de gedisciplineerde manier waarop PKI-generaties altijd zijn geroteerd, en het betekent dat u vandaag nog kunt beginnen met de evaluatie zonder enig risico voor de productie-uitgifte.

De CA installeren

In de AD CS-configuratiewizard van Server Manager verschijnen de drie ML-DSA-parameterreeksen nu in de lijst met sleutelalgoritmen naast RSA en ECDSA. Door er één te selecteren, wordt de hashlijst samengevouwen tot NoHash.

Opmerking: de NoHash-val. U moet -HashAlgorithmName “NoHash” expliciet doorgeven. De AD CS-installatie-engine initialiseert de standaardinstellingen met RSA en SHA-256, en behoudt deze SHA-256-hash zelfs nadat u het sleutelalgoritme wijzigt naar ML-DSA. Een ML-DSA-installatie waarbij deze parameter ontbreekt, mislukt daarom. Dezelfde logica geldt voor automatisering: elk implementatiescript dat SHA256 hardcodeert, heeft een voorwaardelijke vertakking nodig voordat het een PQ CA benadert.

Na de installatie toont certsrv.msc precies wat je zou verwachten: de Microsoft Software Key Storage Provider met een ML-DSA-sleutel, hash-algoritme NoHash en een CA-certificaat met ML-DSA-ondertekeningsalgoritme. Het opbouwen van de certificaatketen, de CDP/AIA-publicatie en de gezondheidscontroles van pkiview.msc verlopen normaal.

Certificaatsjablonen: vijf instellingen die alles reguleren

ML-DSA verschijnt alleen in het tabblad Cryptografie van de sjabloon als de sjabloon correct is opgebouwd, en verschillende van de vereisten zijn direct terug te voeren op "alleen handtekeningen":

Sjabloon instellingVereiste waardeWaarom dit zo belangrijk is
Cryptografische providercategorieCNG-sleutelopslagproviderPQC bestaat alleen in de CNG-stack; oudere CSP-gebaseerde templates zullen ML-DSA nooit vermelden.
Compatibiliteit (CA en ontvanger)Windows Server 2008 of laterCNG-leveranciers verschijnen alleen in de leverancierslijst als ze dit compatibiliteitsniveau of hoger hebben.
Verzoekafhandeling → DoelHandtekening: preciesDit is de valkuil die mensen een middag kost: bij elk ander doel (inclusief "Handtekening en versleuteling") verdwijnt ML-DSA stilletjes uit het tabblad Cryptografie.
Toepassingsbeleid (EKU)Geen EFS, geen beveiligde e-mail.Beide impliceren versleutelingsbewerkingen die ML-DSA niet kan uitvoeren.
Sleutelgebruik-uitbreidingGeen sleutelversleuteling, geen sleutelovereenkomstDezelfde reden: het sleutelpaar kan geen geheimen vaststellen of overdragen.

Inschrijving, OCSP en codeondertekening

Inschrijving werkt momenteel via de MMC-wizard voor certificaten en certreq.exe vanaf gepatchte Windows 11 24H2/25H2-clients. Inschrijving via NDES (SCEP) is expliciet nog niet beschikbaar: relevant als uw via MDM uitgegeven apparaatcertificaten afhankelijk zijn van NDES.

Opmerking: de client met gedeeltelijke updates. Op een Windows 11-client met gedeeltelijke updates kan de wizard voor aanmelding ML-DSA weergeven, maar vervolgens mislukken tijdens de daadwerkelijke aanmelding. Controleer het veld 'Sleutelgrootte' in de wizard om te achterhalen waarom: een reële waarde (10,496 / 15,616 / 20,736) betekent dat de client volledig is ingeschakeld, terwijl 0 betekent dat het algoritme slechts gedeeltelijk is geactiveerd in de sleutelopslag van de client. Voltooi de updates voordat u de certificeringsinstantie de schuld geeft.

De online responder accepteert een ML-DSA OCSP-certificaat voor het ondertekenen van antwoorden (kopieer de standaardsjabloon in plaats van deze te bewerken) en ondertekent antwoorden zonder problemen. Een klein cosmetisch detail: de eigenschap `hash-algorithm` van de responder kan een onzinnige waarde weergeven voor ML-DSA-configuraties, omdat er geen hash is om weer te geven. Negeer de tekenreeks en vertrouw op pkiview.msc , dat meldt dat de responder in orde is. Authenticode is eveneens compleet: ondertekenen en verifiëren met `Set-AuthenticodeSignature` / `Get-AuthenticodeSignature` werkt volledig, waardoor interne codeondertekening een van de meest betrouwbare eerste productieworkloads is voor een PQ-hiërarchie.

Wat is er nog niet?

Een eerlijke inschatting van de omvang van het project is de helft van goed advieswerk, dus hier is de huidige grens in één oogopslag:

Werkt vandaag (Fase 1)Nog niet / gepland
ML-DSA Root-, Sub-, Enterprise- en Standalone-CA's (nieuwe installaties)Migratie ter plaatse of vernieuwing van bestaande CA's door middel van algoritmewijzigingen: zal niet plaatsvinden; plan parallelle hiërarchieën.
ML-DSA-bladuitgifte: codeondertekening, webserver, gebruiker, computersjablonenNDES/SCEP-inschrijving; volledige CEP/CES-webservice-dekking (toegezegd, stapsgewijs)
Inschrijving via Certificates MMC en certreq.exeIIS HTTPS-bindingen met ML-DSA-servercertificaten: Schannel TLS-authenticatie is hiervoor nog niet ingeschakeld.
OCSP-reactieondertekening met ML-DSAKerberos/PKINIT en aanmeldingsprocessen met smartcards
Authenticode codeondertekening en -verificatie; .NET 10 MLDsa API'sAlles wat versleuteld is (EFS, S/MIME-versleuteling): dit is zo ontworpen totdat ML-KEM beschikbaar komt.
Ondersteuning voor Windows Server 2025 + Windows 11 24H2/25H2-platformenGecombineerde ML-DSA/ML-KEM-certificaten (Fase 2); Windows Server 2019/2022 (geen backport verwacht)

Lees de rechterkolom aandachtig door voordat u iemand een 'kwantumveilig intranet' belooft. De release van vandaag beveiligt het uitgifte- en ondertekeningsvlak . Het sessievlak (TLS-sleuteluitwisseling, en daarmee de bescherming tegen het 'nu verzamelen, later decoderen' van gegevens in beweging) wacht op de integratie van ML-KEM via de TLS-stack. Externe partijen die afhankelijk zijn van certificaten bevinden zich op een eigen terrein: veel applicaties, apparaten en HSM-gerelateerde middleware kunnen nog geen ML-DSA-certificaten verwerken, dus elke pilot heeft een compatibiliteitsmatrix nodig, geen aanname.

Operationele realiteit: omvang, HSM's en het beheren van twee PKI's

Alles wordt groter.

De kosten voor Lattice-beveiliging worden in bytes betaald. Vergelijk de gegevens die uw infrastructuur daadwerkelijk verplaatst en opslaat:

AlgoritmePublieke sleutelSignatureHandtekening versus RSA-2048
RSA-2048256 B256 B1× (basislijn)
ECDSA P-256~ 64 B~ 70 B~0.3×
ML-DSA-441,312 B2,420 B~9×
ML-DSA-651,952 B3,309 B~13×
ML-DSA-872,592 B4,627 B~18×

Een bladcertificaat dat met RSA ongeveer 1-1.5 KB weegt, komt bij ML-DSA-65 uit op 6-7 KB als je rekening houdt met de ingebedde publieke sleutel en de handtekening van de uitgevende CA; een keten van drie niveaus overschrijdt de 20 KB nog voordat de handshake begint. OCSP-reacties groeien met een handtekening plus, doorgaans, een ingebed ondertekeningscertificaat. Houd nu al rekening met de gevolgen: bandbreedte en caching van CDP/AIA en OCSP, certificaatarchieven en de CA-database, CLM-inventarissen, TLS-record- en MTU-gedrag zodra ML-KEM-handshakes binnenkomen, en harde capaciteitslimieten voor smartcards, TPM's en apparaten met beperkte resources. Niets hiervan is onoverkomelijk (openbare web-PKI's ondergaan dezelfde verschuiving), maar het hoort thuis in je capaciteitsmodel, niet in je incidentanalyse achteraf.

HSM's: controleer voordat u iets belooft

De fase 1-ervaring draait op de Microsoft Software Key Storage Provider, wat prima is voor testomgevingen en veel interne hiërarchieën. Productieomgevingen en uitgevende CA's in gereguleerde omgevingen zullen hardware-ondersteunde ML-DSA-sleutels willen, en dat hangt volledig af van de CNG-provider van uw HSM-leverancier die het algoritme beschikbaar stelt op firmware die (of op weg is om) FIPS 140-3-gevalideerd is. De grote leveranciers (Thales Luna, entrust nShield, cloud HSM-services) hebben in recente firmwaregeneraties FIPS 203/204-ondersteuning toegevoegd, maar de validatiestatus en de volwassenheid van de KSP-integratie variëren per model en release. Neem "laat me ML-DSA zien via uw CNG KSP en laat me de validatiedocumentatie zien" letterlijk op in uw pilotplan en besluit bewust of de eerste fasen op software-sleutels draaien totdat de hardware is bijgewerkt.

Je zult jarenlang twee PKI's tegelijk gebruiken.

Een parallelle hiërarchie is geen weekendlab: het is een tweede productieomgeving met eigen sjablonen, CDP/AIA-publicatie, OCSP, monitoring, sleutelceremonies, CP/CPS-delta's en uiteindelijk een uitfaseringplan voor de klassieke kant. Organisaties die dit goed aanpakken, beschouwen de transitie als een programma voor crypto-flexibiliteit : als de uitgifte en verlenging van certificaten al geautomatiseerd en op voorraad gebaseerd zijn, wordt het wisselen van algoritmes een configuratiewijziging die door machines wordt uitgevoerd. Als uw certificaten nog steeds worden verlengd met spreadsheets en agendaherinneringen, zal de PQC-migratie aanvoelen als de uitfasering van SHA-1, maar dan voor elk certificaat dat u bezit, met grotere datasets en strengere deadlines.

Een pragmatische migratietijdlijn

Door de wettelijke data te koppelen aan concrete PKI-werkzaamheden ontstaat een vijfstappenplan. De onderstaande tijdsvensters gaan uit van een onderneming van aanzienlijke omvang die ongeveer nu van start gaat; pas de tijdsvensters naar wens aan, maar behoud de volgorde: elke fase vermindert de risico's voor de volgende.

FasevensterWat moet je nu precies doen?
0. Inventaris- en blootstellingsmappingNu – eind 2026Stel een cryptografische inventaris samen. (een CBOM) voor CA's, sjablonen, sleutels, protocollen, applicaties en embedded apparaten. Markeer de twee risicovolle categorieën: langlevende handtekeningen (roots, code-/firmwareondertekening, documentvertrouwen) en gegevens met een lange vertrouwelijkheid die worden blootgesteld aan het principe 'nu verzamelen, later decoderen'. Breng CA-platforms naar Windows Server 2025 en het clientnetwerk naar de PQC-compatibele basislijn.
1. Parallelle PQ-piloot2026 - 2027Zet een geïsoleerde ML-DSA-hiërarchie met twee niveaus op in het lab. Test de CA-installatie, sjablonen, MMC/certreq-registratie, OCSP en Authenticode van begin tot eind. Voer een compatibiliteitsanalyse uit voor de relying party (Windows, OpenSSL 3.5+, Java, netwerkapparatuur, middleware). Meet de verschillen in omvang en prestaties. Stel nu de CP/CPS-wijzigingen en HSM-vereisten op, nu er nog geen dringende zaken zijn.
2. Gerichte productie-inzet2027 - 2028Verplaats eerst de taken voor gesloten-lus-ondertekening (interne codeondertekening, infrastructuurattestatie, documentondertekening) waarbij u elke validator beheert. Gebruik samengestelde certificaten voor paden met gemengd vertrouwen zodra fase 2 wordt uitgerold. Integreer PQC-ondersteuning in de aanbestedingsvoorwaarden, zodat elk nieuw apparaat, HSM en applicatie gebruiksklaar is.
3. Hiërarchieovergang2028 - 2030Geef de volgende generatie rootcertificaten en uitgevende certificeringsinstanties uit als ML-DSA of composiet. Kies standaard voor nieuwe uitgiften die afwijken van RSA-2048 en P-256, vóór de uitfasering in 2030. Integreer ML-KEM voor TLS als Windows en schakel dit in uw load-balancing/inspectie-stack in.
4. Vermogensoverdracht en pensionering2030 - 2033Migreer bladerlandgoederen in bulk met behulp van geautomatiseerde tools voor de levenscyclus van certificatenGezien de huidige aantallen certificaten en de steeds korter wordende geldigheidsduur, is handmatige migratie geen eenvoudige berekening. De klassieke certificaathiërarchieën moeten volgens een gepubliceerd schema worden uitgefaseerd, in lijn met Microsofts eigen doelstelling voor een volledige transitie in 2033.
Absoluut einde2035RSA, ECDSA en klassieke DH zijn niet toegestaan ​​volgens NIST IR 8547. Niets dat kwetsbaar is voor kwantumbeveiliging mag in de vertrouwenspaden van productieomgevingen aanwezig blijven.

Wat dit zegt over de toekomst van AD CS

Er is hier een signaal van de tweede orde dat het benoemen waard is. Tien jaar lang was de veilige aanname dat er nooit meer significant in AD CS zou worden geïnvesteerd, en platformbeslissingen werden daarop afgestemd. Het uitbrengen van een gloednieuw NIST-ondertekeningsalgoritme (met een gepubliceerd meerfasenplan dat ML-KEM, samengestelde certificaten en de diensten voor de registratierol omvat) is geen gedrag dat past bij de onderhoudsmodus.

De timing valt samen met een stillere verschuiving in het ecosysteem van publiek vertrouwen: publieke CA's verwijderen de Client Authentication EKU uit TLS-certificaten, omdat rootprogramma's het vertrouwen tussen server en client scheiden. Dit betekent dat de enorme wereld van mTLS (service meshes, apparaatvloten, B2B API-authenticatie) migreert naar private CA's, of iemand dit nu gepland had of niet. Een private CA-platform dat is inbegrepen in de OS-licentie, integreert met AD Identity en nu ondertekent met post-quantum algoritmen, is plotseling een zeer logische bestemming voor deze workloads. AD CS overleeft niet alleen de PQC-transitie; het gebruikt deze om opnieuw deel te nemen aan het gesprek.

PQC Adviesdiensten

Bereik post-quantum paraatheid met een door experts geleide cryptografische beoordeling, migratiestrategie en praktische implementatie conform de NIST-normen.

Hoe kan Encryption Consulting u helpen?

Alles hierboven komt neer op een kwestie van volgorde bepalen: weet wat je hebt, bewijs wat werkt, automatiseer de wisseling en houd je aan de data die al in de agenda staan. Dat is precies waar Encryption Consulting dagelijks mee bezig is: we hebben meer dan 100 Fortune 500-bedrijven geholpen bij het beoordelen, ontwerpen en beheren van hun cryptografische infrastructuur, en onze PQC Advisory Services zijn speciaal voor deze transitie ontwikkeld.

Waar teams vastlopenHoe we helpen
"We weten eigenlijk niet waar kwantumgevoelige cryptografie zich in onze omgeving bevindt."Onze PQC-adviesopdracht begint met een kwantumdreigingsanalyse, en CBOM Secure Bouwt een geautomatiseerde, continu bijgewerkte cryptografische materiaallijst op voor certificaten, sleutels, algoritmen en protocollen: de inventaris waarop elke volgende fase is gebaseerd.
“We hebben een verdedigbaar stappenplan nodig, geen wetenschappelijk experiment.”We leveren een routekaart en strategie voor kwantumgereedheid die is afgestemd op de richtlijnen van NIST, CISA en NSA: gefaseerde mijlpalen, een cryptografisch flexibel operationeel model en proof-of-conceptvalidatie van kandidaat-algoritmen voordat ze in productie worden genomen.
"Onze AD CS-omgeving heeft een parallelle PQ-hiërarchie nodig die correct is ontworpen."Het PKI-beoordeling De ontwerp- en implementatiediensten omvatten hiërarchische architectuur, HSM-integratie, CP/CPS-ontwikkeling en sjabloonbeheer. PKI-as-a-Service Je kunt de post-kwantumgeneratie hosten op FIPS 140-3 Level 3 HSM's als je die liever gebruikt dan zelf bouwt.
"Wanneer het algoritme verandert, moeten we tienduizenden certificaten overzetten."CertSecure ManagerOns platform voor certificaatlevenscyclusbeheer is gebouwd met crypto-flexibiliteit als kern: continue detectie in AD CS, HashiCorp Vault, de cloud en appliance-omgevingen, risicogeprofileerde inventarisatie en zero-touch vernieuwing op vlootniveau: zo wordt een algoritmemigratie een beleidswijziging in plaats van een project dat meerdere kwartalen in beslag neemt.
"Onze codeondertekeningstechnologie moet de overgang ongeschonden doorstaan."CodeSign Secure Biedt beleidsgestuurde, HSM-ondersteunde ondertekeningsworkflows voor Windows, Linux, macOS en CI/CD-pipelines: het natuurlijke controlepaneel voor het overzetten van Authenticode en firmware-ondertekening naar post-kwantumalgoritmen.

Veelgestelde Vragen / FAQ

Kan ik mijn bestaande AD CS CA upgraden naar ML-DSA?

Nee. ML-DSA CA's moeten nieuw geïnstalleerd worden: er is geen conversie ter plaatse en geen mogelijkheid tot vernieuwing met een nieuw algoritme, aangezien het wijzigen van het publieke-sleutelalgoritme een nieuwe sleutel en een nieuwe CA-identiteit vereist. Het ondersteunde model is een parallelle post-quantum hiërarchie die naast uw bestaande PKI opereert terwijl workloads worden gemigreerd.

Maakt ML-DSA in AD CS mijn TLS kwantumveilig?

Nog niet. ML-DSA dekt handtekeningen: certificaat- en OCSP-integriteit, codeondertekening en authenticatie van identiteiten. Sessievertrouwelijkheid is afhankelijk van de sleuteluitwisseling, waarvoor ML-KEM via de TLS-stack nodig is; IIS zal momenteel zelfs geen ML-DSA-servercertificaat koppelen voor HTTPS . Bescherming tegen het direct verzamelen en later decoderen van data tijdens transport komt pas in de sleutelinkapselingsfase, niet in deze fase.

Op welke parameterreeks moet ik standaardiseren?

ML-DSA-65 (NIST Categorie 3) is de pragmatische standaard voor het uitgeven van CA's en bladcertificaten. Reserveer ML-DSA-87 voor rootcertificaten en langlevende ankercertificaten waar de maximale marge de omvang rechtvaardigt, en beschouw ML-DSA-44 als een bewuste uitzondering voor scenario's met beperkte omvang waar Categorie 2 een aanvaardbare risicobeslissing is.

Waarom kan ik geen hash-algoritme meer kiezen?

Omdat FIPS 204 de berichtverwerking in het ondertekeningsschema zelf integreert, is er geen aparte stap voor hashing en ondertekening die geconfigureerd hoeft te worden. AD CS geeft dit weer als de enkele optie NoHash. Vergeet niet deze expliciet door te geven bij installaties via scripts; de standaardinstellingen van de installatie-engine blijven RSA/SHA-256 en worden niet automatisch gecorrigeerd wanneer u een ML-DSA-sleutel selecteert.

Krijgt Windows Server 2019 of 2022 ondersteuning voor PQC?

Er zijn geen aanwijzingen voor een backport: PQC in AD CS is een functionaliteit van Windows Server 2025. Als uw CA's op oudere platforms draaien, valt de OS-upgrade nu onder het kritieke pad na de quantumupdate en hoort deze thuis in het plan voor volgend jaar, niet voor 2030.

Wanneer moeten we echt in actie komen?

De druk om RSA-2048 en ECDSA P-256 uit te faseren begint in 2030 onder NIST IR 8547, met een strikt verbod op alle kwantumgevoelige publieke-sleutelalgoritmen in 2035, en CNSA 2.0 begint de kwestie al in 2027 af te dwingen via de aanbesteding. Maar de werkelijke dwingende factor is de geldigheidsduur van uw eigen certificaten: langlopende ankercertificaten die vandaag worden uitgegeven, overlappen die datums al. De inventarisatie moet nu beginnen; de algoritme-wissel vindt dan plaats volgens uw eigen planning in plaats van die van een auditor.

Conclusie

De update van mei 2026 kan het beste worden gezien als een startschot. AD CS kan nu een volledig post-quantum ondertekeningsplatform (CA-hiërarchie, uitgifte, OCSP, codeondertekening ) bouwen op basis van gestandaardiseerde, door NIST goedgekeurde cryptografie, waarbij sleutelinkapseling en samengestelde certificaten al op de gepubliceerde roadmap staan. De technologische vraag is verschoven van "wanneer stapt Microsoft over?" naar "hoe klaar is mijn omgeving om te volgen?"

De onzekerheid over kwantumhardware werkt twee kanten op, maar de nalevingskalender niet: 2030 en 2035 staan ​​vast, en de vertrouwensankers die vandaag worden ondertekend, zullen nog steeds geldig zijn wanneer die data aanbreken. De organisaties die deze transitie rustig zullen doorstaan, zijn degenen die het benaderen als een programma voor crypto-flexibiliteit: inventaris eerst, automatisering daarna, algoritmes als derde. Zet de labhiërarchie op, spoor incompatibiliteiten op terwijl ze nog goedkoop zijn, en laat de omschakeling zelf saai zijn. Zo ziet goede PKI-engineering er altijd uit.

Referenties en verder lezen