- Key Takeaways
- Een stille update met grote gevolgen.
- Waarom post-kwantumcryptografie nodig is en waarom PKI de eerste in lijn is.
- De normen achter de verschuiving
- De klok waar je daadwerkelijk tegen racet
- Wat Microsoft daadwerkelijk heeft uitgebracht in AD CS
- ML-DSA onder de motorkap: wat PKI-engineers moeten weten
- Zuivere versus samengestelde certificaten: de transitievraag.
- Een ML-DSA CA opzetten: wat werkt vandaag de dag?
- Wat is er nog niet?
- Operationele realiteit: omvang, HSM's en het beheren van twee PKI's
- Een pragmatische migratietijdlijn
- Wat dit zegt over de toekomst van AD CS
- Hoe kan Encryption Consulting u helpen?
- Veelgestelde Vragen / FAQ
- Conclusie
- Referenties en verder lezen
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:
| Standaard | Algoritme (afstamming) | Doel | Status in Windows |
|---|---|---|---|
| FIPS204 | ML-DSA (KRISTALLEN-Dilithium) | Digitale handtekeningen | GA, en nu live in AD CS |
| FIPS203 | ML-KEM (CRYSTALS-Kyber) | Sleutelversleuteling / sleuteluitwisseling | Algemene beschikbaarheid in CNG API's; AD CS-ondersteuning gepland (fase 2) |
| FIPS205 | SLH-DSA (SPHINCS+) | Staatloze hash-gebaseerde handtekeningen | Beschikbaar 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:
| Datum | Milestone |
|---|---|
| augustus 2024 | NIST rondt FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en af. FIPS205 (SLH-DSA). |
| november 2024 | NIST IR 8547 (concept), Overgang naar post-kwantumcryptografiestandaarden, publiceert het stappenplan voor de uitfasering van RSA. ECDSA, ECDH, DSA en eindige-veld DH. |
| 2025 | Microsoft 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 2025 | PQC 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. |
| 2027 | NSA CNSA 2.0Nieuwe aankopen voor de Amerikaanse nationale veiligheidssystemen moeten kwantumresistente algoritmen ondersteunen. |
| 2029 | Het uitgesproken doel van Microsoft is om PQC zo snel mogelijk in al haar eigen producten en diensten te implementeren. |
| 2030 | NIST IR 8547: algoritmen op het 112-bits beveiligingsniveau (RSA-2048 en ECDSA P-256) zijn verouderd. Voortgezet gebruik vereist een gedocumenteerde risicoacceptatie. |
| 2033 | Microsoft streeft ernaar de overstap naar PQC twee jaar vóór de federale deadline af te ronden. |
| 2035 | NIST 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.
| Bekwaamheid | Standaard | Doel | AD CS-status |
|---|---|---|---|
| ML-DSA (zuiver) | FIPS204 | PQ digitale handtekeningen | Nu beschikbaar (Fase 1) |
| ML-KEM | FIPS203 | PQ-sleutelinkapseling | Gepland (Fase 2) |
| Samengestelde ML-DSA | IETF LAMPS-ontwerp | Klassieke handtekening + PQ-handtekening in één certificaat | Gepland (Fase 2) |
| Samengestelde ML-KEM | IETF LAMPS-ontwerp | Klassieke + PQ-sleutelinkapseling | Gepland (Fase 2) |
| CEP / CES / NDES / OCSP rol-service dekking | NB | PQ-inschrijving en -intrekking loodgieterswerk | Toegewijd; 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:
| Parameterset | NIST-categorie | Publieke sleutel | Privésleutel | Signature | "Toetsgrootte" weergegeven in de Windows-interface |
|---|---|---|---|---|---|
| ML-DSA-44 | Niveau 2 | 1,312 B | 2,560 B | 2,420 B | 10,496 beetjes |
| ML-DSA-65 | Niveau 3 | 1,952 B | 4,032 B | 3,309 B | 15,616 beetjes |
| ML-DSA-87 | Niveau 5 | 2,592 B | 4,896 B | 4,627 B | 20,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.
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 instelling | Vereiste waarde | Waarom dit zo belangrijk is |
|---|---|---|
| Cryptografische providercategorie | CNG-sleutelopslagprovider | PQC bestaat alleen in de CNG-stack; oudere CSP-gebaseerde templates zullen ML-DSA nooit vermelden. |
| Compatibiliteit (CA en ontvanger) | Windows Server 2008 of later | CNG-leveranciers verschijnen alleen in de leverancierslijst als ze dit compatibiliteitsniveau of hoger hebben. |
| Verzoekafhandeling → Doel | Handtekening: precies | Dit 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-uitbreiding | Geen sleutelversleuteling, geen sleutelovereenkomst | Dezelfde 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, computersjablonen | NDES/SCEP-inschrijving; volledige CEP/CES-webservice-dekking (toegezegd, stapsgewijs) |
| Inschrijving via Certificates MMC en certreq.exe | IIS HTTPS-bindingen met ML-DSA-servercertificaten: Schannel TLS-authenticatie is hiervoor nog niet ingeschakeld. |
| OCSP-reactieondertekening met ML-DSA | Kerberos/PKINIT en aanmeldingsprocessen met smartcards |
| Authenticode codeondertekening en -verificatie; .NET 10 MLDsa API's | Alles 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-platformen | Gecombineerde 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:
| Algoritme | Publieke sleutel | Signature | Handtekening versus RSA-2048 |
|---|---|---|---|
| RSA-2048 | 256 B | 256 B | 1× (basislijn) |
| ECDSA P-256 | ~ 64 B | ~ 70 B | ~0.3× |
| ML-DSA-44 | 1,312 B | 2,420 B | ~9× |
| ML-DSA-65 | 1,952 B | 3,309 B | ~13× |
| ML-DSA-87 | 2,592 B | 4,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.
| Fase | venster | Wat moet je nu precies doen? |
|---|---|---|
| 0. Inventaris- en blootstellingsmapping | Nu – eind 2026 | Stel 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-piloot | 2026 - 2027 | Zet 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-inzet | 2027 - 2028 | Verplaats 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ërarchieovergang | 2028 - 2030 | Geef 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 pensionering | 2030 - 2033 | Migreer 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 einde | 2035 | RSA, 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.
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 vastlopen | Hoe 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
- Overzicht van post-kwantumcryptografie in AD CS (Microsoft Learn)
- Wat is ML-DSA-ondersteuning in AD CS? (Microsoft Learn)
- KB5087539: Beveiligingsupdate van 12 mei 2026 voor Windows Server 2025
- Microsoft Security Community: API's voor post-kwantumcryptografie zijn nu algemeen beschikbaar op Microsoft-platformen.
- Key Takeaways
- Een stille update met grote gevolgen.
- Waarom post-kwantumcryptografie nodig is en waarom PKI de eerste in lijn is.
- De normen achter de verschuiving
- De klok waar je daadwerkelijk tegen racet
- Wat Microsoft daadwerkelijk heeft uitgebracht in AD CS
- ML-DSA onder de motorkap: wat PKI-engineers moeten weten
- Zuivere versus samengestelde certificaten: de transitievraag.
- Een ML-DSA CA opzetten: wat werkt vandaag de dag?
- Wat is er nog niet?
- Operationele realiteit: omvang, HSM's en het beheren van twee PKI's
- Een pragmatische migratietijdlijn
- Wat dit zegt over de toekomst van AD CS
- Hoe kan Encryption Consulting u helpen?
- Veelgestelde Vragen / FAQ
- Conclusie
- Referenties en verder lezen
