Certificaatsjablonen: Hoe Microsoft AD CS de uitgifte beheert

Een certificaatsjabloon is een vooraf gedefinieerde set regels, opgeslagen in Active Directory, die een Enterprise Certification Authority toepast telkens wanneer een certificaat wordt uitgegeven. Sjablonen bepalen wat een certificaat bevat, wie het mag aanvragen, hoe lang het geldig is, welke cryptografische instellingen het gebruikt en waarvoor het kan worden gebruikt. Ze zorgen ervoor dat de uitgifte van certificaten binnen Microsoft Active Directory Certificate Services (AD CS) consistent, herhaalbaar en eenvoudig te beheren is, in plaats van dat elke aanvrager zelf eigenschappen moet definiëren.

Bedrijven kunnen jaarlijks honderdduizenden digitale certificaten uitgeven en beheren voor gebruikers, computers, webservers, applicaties, apparaten, VPN's en smartcards. Als elke aanvraag handmatig geconfigureerd zou moeten worden, zou certificaatbeheer al snel inconsistent, traag en moeilijk te beveiligen worden. Microsoft biedt hiervoor een oplossing met certificaatsjablonen.

Certificaatsjablonen zijn de regelsets die AD CS Enterprise CA's gebruiken om de uitgifte te standaardiseren. In plaats van elke aanvrager onafhankelijk certificaateigenschappen te laten kiezen, specificeert een sjabloon precies wat een certificaat moet bevatten, wie het kan aanvragen, hoe lang het geldig blijft, welke algoritmen het gebruikt en waarvoor het gebruikt mag worden.

Een belangrijk punt om in gedachten te houden: in tegenstelling tot certificaten zelf, maken certificaatsjablonen geen deel uit van de X.509-standaard . Ze zijn een Microsoft-specifieke functionaliteit in Enterprise CA's die zijn geïntegreerd met Active Directory. Organisaties die gebruikmaken van standalone CA's of andere PKI-platformen kunnen vergelijkbare beleidsmaatregelen toepassen, maar zij gebruiken geen Microsoft-certificaatsjablonen.

Wat is een certificaatsjabloon?

Een certificaatsjabloon is een Active Directory-object dat het beleid definieert dat een Enterprise CA toepast bij het uitgeven van een certificaat. Het fungeert als een blauwdruk voor de inhoud van het certificaat en de vereisten voor de inschrijving ervan.

Wanneer een gebruiker, computer of applicatie een aanvraag indient, identificeert de Enterprise CA de aangevraagde sjabloon, controleert of de aanvrager gemachtigd is om deze te gebruiken en geeft een certificaat uit dat overeenkomt met de configuratie van de sjabloon. Dit elimineert handmatige besluitvorming tijdens de inschrijving en zorgt voor consistente certificaten binnen de organisatie. Een sjabloon kan het doel van het certificaat, de indeling van de onderwerpnaam, de sleutelgrootte, de cryptografische provider, de geldigheids- en verlengingsperioden, het sleutelgebruik, het uitgebreide sleutelgebruik (EKU), inschrijvingsrechten en de instellingen voor de privésleutel definiëren. Omdat deze beleidsregels centraal in Active Directory worden beheerd, kunnen beheerders de uitgifte vanuit één centrale locatie beheren in plaats van elk certificaat afzonderlijk te configureren.

Hoe certificaatsjablonen werken

De inschrijving begint wanneer een gebruiker, apparaat of service een certificaat aanvraagt. De aanvraag verwijst naar een specifieke sjabloon en de Enterprise CA haalt de configuratie van die sjabloon op uit Active Directory.

Voordat een certificaat wordt uitgegeven, evalueert de certificeringsinstantie (CA) verschillende voorwaarden. Het bevestigt dat de aanvrager de juiste inschrijfrechten heeft, past eventueel vereist goedkeuringsbeleid toe, controleert de cryptografische vereisten en valideert of aan de voorwaarden van de sjabloon is voldaan. Pas daarna genereert het een certificaat dat aan de sjabloon voldoet. De scheiding van taken is hierbij cruciaal: de sjabloon definieert het uitgiftebeleid en de Enterprise CA handhaaft dat beleid tijdens de inschrijving.

Wat een certificaatsjabloon definieert

Een sjabloon kan vrijwel elk aspect van een uitgegeven certificaat beheren. De instellingen die beheerders het vaakst configureren, staan ​​hieronder.

Sjabloon instelling	Doel
Doel van het certificaat	Of het certificaat nu bedoeld is voor gebruikers, computers, webservers, codeondertekening, smartcards of andere toepassingen.
Onderwerp	Hoe de identiteit wordt ingevuld: automatisch vanuit Active Directory of door de aanvrager aangeleverd?
Cryptografische instellingen	Belangrijkste algoritme, sleutellengte, cryptografische aanbieder en hashvereisten
Geldigheidsduur	De geldigheidsduur van het certificaat en de timing van de verlenging.
Kerngebruik en EKU's	Hoe het certificaat gebruikt kan worden, bijvoorbeeld voor TLS-serverauthenticatie, clientauthenticatie of codeondertekening.
Toestemmingen voor inschrijving	Welke gebruikers, groepen of computers mogen het certificaat aanvragen?
Bescherming van privésleutels	Exporteerbaarheid, archivering, hardwarematige opslag en alle vereisten voor gebruikersinteractie.

Deze controles zorgen ervoor dat certificaten geschikt blijven voor het beoogde gebruik en verminderen tegelijkertijd configuratiefouten.

Certificaatsjabloonversies

AD CS heeft in de loop van de ontwikkeling van Windows Server verschillende sjabloonversies geïntroduceerd, vaak schemaversies genoemd. Het is belangrijk om de juiste versie te kiezen, omdat cryptografische mogelijkheden zoals CNG ervan afhankelijk zijn.

Versie	Geïntroduceerd met	Belangrijkste mogelijkheden
versie 1	Windows 2000	Ingebouwde sjablonen die niet kunnen worden gewijzigd; alleen hun machtigingen kunnen worden aangepast.
versie 2	Windows Server 2003	Aanpasbare sjablonen, inschrijfrechten, het vervangen van sjablonen, het archiveren van sleutels en ondersteuning voor automatische inschrijving.
versie 3	Windows Server 2008	Alle functies van versie 2 plus Cryptography Next Generation (CNG), Key Storage Providers (KSP's) en elliptische-curve-cryptografie (let op: het NSA Suite B-algoritmeprofiel dat met deze versie werd geïntroduceerd, werd in 2015 vervangen door CNSA 1.0 en in 2022 door CNSA 2.0).
versie 4	Windows Server 2012	TPM-sleutelattestatie, sleutelgebaseerde verlenging, verlenging met dezelfde sleutel en de mogelijkheid om meerdere providers op te geven.

Moderne implementaties gebruiken over het algemeen sjablonen van versie 3 of versie 4, omdat deze de huidige cryptografische providers en standaarden ondersteunen. Omdat een sjabloon van versie 4 een CA met Windows Server 2012 of later en een ontvanger met Windows 8 of later vereist, bepalen de compatibiliteitsinstellingen van het sjabloon welke schemaversie daadwerkelijk wordt aangemaakt.

Sjablonen voor voorbereiding op de periode na de kwantumperiode en certificaten

Microsoft Active Directory Certificate Services op Windows Server 2025 ondersteunt nu post-kwantumcryptografie. De Patch Tuesday-update van mei 2026 introduceerde ML-DSA-44, ML-DSA-65 en ML-DSA-87, het op module-roosters gebaseerde digitale handtekeningalgoritme dat door NIST is gestandaardiseerd als FIPS 204, voor certificaatondertekeningsbewerkingen in AD CS.

Certificatensjablonen voor post-quantumcertificaten hebben twee vereisten: het sjabloon moet gebruikmaken van een CNG-sleutelopslagprovider (en niet van een traditionele cryptografische serviceprovider), en het doel van de aanvraagafhandeling moet worden ingesteld op 'Ondertekening', aangezien ML-DSA alleen ondertekeningsbewerkingen ondersteunt. Deze vereisten betekenen dat alleen sjablonen van versie 3 of versie 4 PQC-algoritmen kunnen bevatten.

Samengestelde certificaten, die een klassiek algoritme zoals ECDSA combineren met een ML-DSA-handtekening, worden ook ondersteund. Hierdoor kunnen vertrouwende partijen die post-quantumformaten nog niet begrijpen, handtekeningen blijven valideren met behulp van de klassieke component.

Organisaties die een PQC-migratie plannen , moeten er rekening mee houden dat bestaande certificeringsinstanties niet ter plaatse kunnen worden geüpgraded. Ondersteuning na de kwantumupdate vereist de implementatie van een nieuwe, parallelle CA-hiërarchie naast de bestaande productieomgeving. Cryptografische flexibiliteit, het ontwerpen van sjablonen en inschrijvingsworkflows zodat algoritmekeuzes kunnen worden bijgewerkt zonder een volledige heropbouw van de infrastructuur, zou een leidend principe moeten zijn voor elke sjabloonarchitectuur die tegenwoordig wordt ontworpen.

Voor organisaties die onder CNSA 2.0 vallen, moeten nieuwe acquisities van het National Security System vanaf 1 januari 2027 CNSA 2.0-algoritmen ondersteunen, met een volledige migratie vereist vóór 31 december 2031. NIST IR 8547 stelt een parallelle uitfasering vast voor klassieke asymmetrische algoritmen in het bredere federale en commerciële landschap, met een beoogde uitsluiting in 2035. Bij de planning van certificaatsjablonen, inclusief de migratie van CNG-providers, de selectie van parameterreeksen en het ontwerp van een parallelle CA-hiërarchie, moet rekening worden gehouden met beide tijdlijnen.

Waarom zijn certificaatsjablonen belangrijk?

Sjablonen zijn een van de belangrijkste redenen waarom Enterprise PKI beheersbaar blijft op grote schaal. Zonder een gestandaardiseerd uitgiftebeleid zouden beheerders elk verzoek afzonderlijk moeten beoordelen en configureren, wat zowel de benodigde inspanning als het beveiligingsrisico zou verhogen.

Sjablonen verbeteren de consistentie, omdat vergelijkbare systemen identieke configuraties ontvangen, en ze versterken de beveiliging door goedgekeurde algoritmen af ​​te dwingen, te beperken wie zich kan inschrijven, ongepast gebruik van certificaten te voorkomen en de beleidscontrole centraal te houden. Naarmate organisaties overstappen op kortere certificaatlevensduren en meer automatisering, wordt een consistent uitgiftebeleid steeds belangrijker, en sjablonen vormen de basis die grootschalig certificaatlevenscyclusbeheer praktisch uitvoerbaar maakt.

Veelgemaakte fouten

Een veelgemaakte fout is het aanpassen van ingebouwde versie 1-sjablonen in plaats van ze te dupliceren. De aanbevolen methode is het dupliceren van een bestaand sjabloon, waardoor beheerders instellingen kunnen aanpassen terwijl de standaardwaarden behouden blijven. Het dupliceren van een versie 1-sjabloon zorgt er ook voor dat deze automatisch wordt geüpgraded naar versie 2, waardoor de kwetsbaarheid die werd aangepakt door CVE-2024-49019 (gepatcht in november 2024) wordt verholpen. Deze kwetsbaarheid stelde een aanvaller met inschrijfrechten in staat om willekeurige toepassingsbeleidsregels in een certificaatverzoek in te sluiten en certificaten te verkrijgen die verder gingen dan het beoogde doel van het sjabloon.

Verkeerd geconfigureerde certificaatsjablonen vormen ook een van de meest kritieke manieren om privileges te escaleren in Active Directory-omgevingen. De ESC-kwetsbaarheidsklasse omvat een reeks verkeerde configuraties van sjablonen en CA's die aanvallers in staat stellen certificaten te verkrijgen voor accounts met hoge privileges.

ESC1 treedt op wanneer een sjabloon de vlag 'Enrollee Supplies Subject' heeft ingeschakeld en tegelijkertijd inschrijvingsrechten verleent aan accounts met lage privileges, zoals domeingebruikers. Deze combinatie stelt een aanvaller in staat om een ​​certificaat aan te vragen voor elk account, inclusief een domeinbeheerder, en zich als dat account te authenticeren.

APT29 en UNC5330 maakten in respectievelijk 2022 en 2024 gebruik van dit patroon om een ​​volledige domeincompromis te bereiken. ESC4 ontstaat wanneer accounts met lage privileges schrijfrechten (WriteProperty, WriteDacl of WriteOwner) hebben op een certificaatsjabloonobject in Active Directory, waardoor ze de configuratie van de sjabloon kunnen wijzigen en kwetsbaarheden van het ESC1-type kunnen introduceren.

Beide configuratiefouten kunnen worden voorkomen door strikte sjabloonrechten volgens het principe van minimale bevoegdheden toe te passen, de CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT-vlag uit te schakelen op sjablonen die deze niet vereisen, en door regelmatige controles uit te voeren.

Een ander veelvoorkomend probleem is het te ruim verlenen van inschrijfrechten, omdat het toestaan ​​van onnodige gebruikers of systemen om certificaten aan te vragen het risico op ongeautoriseerde uitgifte en privilege-escalatie vergroot. Beheerders hebben ook de neiging om certificaatdoeleinden te breed te definiëren; het combineren van verschillende niet-gerelateerde EKU's in één sjabloon schendt het principe van minimale bevoegdheden en maakt certificaten moeilijker te beheren gedurende hun levenscyclus.

Ten slotte worden sjablonen vaak niet gecontroleerd, waardoor een sjabloon dat ooit aan het beleid voldeed, verouderd raakt naarmate cryptografische richtlijnen, de geldigheidsduur van certificaten en bedrijfsbehoeften veranderen.

Best practices voor beveiliging

Sjablonen moeten het principe van minimale bevoegdheden volgen, waardoor inschrijving alleen is toegestaan ​​voor geautoriseerde gebruikers, apparaten en services. Vereis sterke algoritmen, geschikte sleutellengtes en niet-exporteerbare privésleutels waar mogelijk, met name voor gevoelige certificaten.

Controleer regelmatig de sjabloonmachtigingen: bevestig dat accounts met beperkte privileges, zoals domeingebruikers en geauthenticeerde gebruikers, geen inschrijfrechten hebben op sjablonen die authenticatie ondersteunen, dat geen enkele niet-PKI-beheerder schrijfrechten (WriteProperty, WriteDacl of WriteOwner) heeft op sjabloonobjecten (ESC4-vector), en dat de vlag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is uitgeschakeld voor alle sjablonen die deze niet expliciet vereisen.

Voer de AD CS-beveiligingsbeoordelingen van Certipy of Microsoft Defender for Identity uit om verkeerd geconfigureerde sjablonen op te sporen. Verwijder verouderde sjablonen zodat ze niet per ongeluk opnieuw gebruikt kunnen worden. Bescherm privésleutels in hardware met behulp van een hardwarebeveiligingsmodule of een TPM om het risico op sleutelcompromittering te verkleinen.

Beperk de reikwijdte van EKU's tot een smal niveau en houd niet-gerelateerde toepassingen in aparte sjablonen in plaats van ze te bundelen.

Integreer sjabloonbeheer met levenscyclusbeheer, zodat uitgegeven certificaten gedurende hun operationele levensduur worden bewaakt, verlengd, ingetrokken en gecontroleerd. Configureer CRL Distribution Point (CDP) en OCSP Authority Information Access (AIA)-extensies in elke sjabloon, zodat vertrouwende partijen de intrekkingsstatus kunnen controleren; sjablonen die extern toegankelijke certificaten aanbieden, moeten publiekelijk bereikbare CDP- en OCSP-URL's specificeren, en geen interne eindpunten.

Als deze stappen consequent worden toegepast, blijven de uitgiften zowel veilig als voorspelbaar naarmate de omgeving groeit.

Hoe encryptieconsultancy kan helpen

Een goed ontworpen template-omgeving maakt het verschil tussen een TLS- en certificaatprogramma dat soepel schaalbaar is en een programma dat risico's met zich meebrengt door een verkeerd geconfigureerd uitgiftebeleid. Als cryptografie-georiënteerde praktijk biedt Encryption Consulting specifieke PKI-expertise die brede cybersecuritybedrijven niet kunnen evenaren.

Via haar Enterprise PKI Services helpt EC bij het ontwerpen, implementeren en optimaliseren van Microsoft AD CS-omgevingen en het bijbehorende uitgiftebeleid. Dit omvat template-architectuur, inschrijvingsworkflows, het ontwerp van de CA-hiërarchie, cryptografisch beleid en governance, waardoor de implementatie klaar is voor audits en in lijn is met NIST, FIPS, eIDAS en WebTrust. De root- en ondergeschikte CA-sleutels worden beschermd door FIPS 140-3 Level 3 HSM's. CertSecure Manager vult AD CS aan met gecentraliseerde certificaatdetectie, inventarisatie, automatisering van de levenscyclus, bewaking van vervaldatums en compliance-rapportage voor de gehele organisatie.

Certificaatproblemen en verlopen referenties zijn te voorkomen risico's, en de experts van EC identificeren en verhelpen deze voordat ze een incident veroorzaken. Terwijl organisaties hun post-quantummigratie plannen, brengt de PQC Readiness Assessment van EC het volledige AD CS-transitiepad in kaart, van het genereren van een cryptografische materiaallijst (CBOM) via CertSecure Manager en het migreren van CSP-gebonden sjablonen naar CNG Key Storage Providers, tot het ontwerpen en implementeren van een parallelle ML-DSA CA-hiërarchie op Windows Server 2025 en het selecteren van de juiste parameterreeksen voor elke certificaatworkload.

Of u nu de uitgifte van certificaten standaardiseert, een verouderde AD CS-implementatie moderniseert of sjablonen voorbereidt voor cryptografische vereisten na het kwantumtijdperk, EC levert zonder onderbrekingen, zodat digitaal vertrouwen behouden blijft in plaats van aan het toeval te worden overgelaten.

Conclusie

Certificaatsjablonen vormen de basis voor het uitgeven van certificaten in Microsoft AD CS. Door te definiëren hoe certificaten worden aangemaakt, wie ze mag aanvragen en hoe ze gedurende hun hele levenscyclus worden beschermd, helpen sjablonen organisaties consistent te blijven, de beveiliging te versterken en certificaatbeheer op grote schaal te automatiseren.

Naarmate bedrijfsomgevingen groeien en de geldigheidsduur van certificaten korter wordt, zijn goed ontworpen sjablonen niet alleen een administratief gemak; ze vormen een fundamenteel onderdeel van veilige, schaalbare PKI-processen. Een praktische eerste stap is het inventariseren van de sjablonen die momenteel op uw certificeringsinstanties (CA's) zijn gepubliceerd, het verwijderen van ongebruikte of te brede sjablonen en het controleren of elk resterend sjabloon de huidige cryptografische instellingen en het principe van minimale bevoegdheden naleeft.