ADCS Open Protocols Specificaties | Encryptieconsultancy

De ADCS Open Protocols zijn de door Microsoft gepubliceerde technische specificaties, zoals MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA en andere, die precies definiëren hoe Windows-clients certificaten aanvragen, hoe certificaatsjablonen zijn gestructureerd en hoe beheerders een certificeringsinstantie beheren. Ze vormen de gezaghebbende referentie voor het beveiligen en controleren van een ADCS-implementatie. Active Directory Certificate Services (ADCS) is een van de meest gebruikte Public Key Infrastructure (PKI)-oplossingen in het bedrijfsleven. Hoewel de meeste organisaties met ADCS communiceren via de Windows-gebruikersinterface of PowerShell, ligt de technische complexiteit in de protocollaag onder de door Microsoft gepubliceerde Open Specifications. Inzicht in deze protocollen is cruciaal voor architecten, beveiligingsengineers, ontwikkelaars van PKI-geïntegreerde tools en beveiligingsprofessionals die kwetsbaarheden in de certificaatinfrastructuur beoordelen.

Deze handleiding biedt een uitgebreide, op de praktijk gerichte analyse van alle belangrijke ADCS Open Protocol-specificaties, hoe ze met elkaar samenhangen en wat elke specificatie betekent voor uw PKI-beveiligingspositie.

Samenvatting

Active Directory Certificate Services (ADCS) draait op een gedefinieerde stapel Microsoft Open Specifications: MS-WCCE en MS-ICPR voor inschrijving, MS-XCEP en MS-WSTEP voor inschrijving via webservices, MS-CRTD voor certificaatsjablonen en MS-CSRA en MS-OCSPA voor CA- en OCSP-beheer. Bijna elk bekend pad voor privilege-escalatie in ADCS, van ESC1 tot en met ESC15, is terug te voeren op een verkeerde configuratie op een van deze protocollagen, meestal in certificaatsjablonen (MS-CRTD) of de inschrijvingsprocedure (MS-WCCE). Ondertussen verkort het voorstel SC-081v3 van het CA/Browser Forum, goedgekeurd op 11 april 2025, de geldigheidsduur van openbare TLS-certificaten tot 47 dagen in maart 2029, waardoor de operationele risico's voor elk certificaat dat via deze protocolstapel wordt uitgegeven, toenemen. Deze handleiding koppelt elk protocol aan zijn rol, de beheerders ervan en de risico's die het met zich meebrengt. Vervolgens biedt het PKI-, beveiligings-, platform- en compliance-teams een concrete checklist voor het beveiligen van hun ADCS-omgeving.

Snelle ADCS-protocolchecklist

Gebruik deze checklist om te bepalen in hoeverre uw ADCS-omgeving is blootgesteld aan bekende risico's op protocolniveau.

Controleer voor elke certificaatsjabloon de onderwerpnaam, EKU en instellingen van de inschrijvingsagent aan de hand van MS-CRTD om ESC1-, ESC2- en ESC3-condities uit te sluiten.
Controleer of de CA de vlag EDITF_ATTRIBUTESUBJECTALTNAME2 niet heeft ingeschakeld (ESC6).
Controleer of elk MS-WSTEP- of CES-eindpunt HTTPS en Extended Protection for Authentication vereist om ESC8-relay-aanvallen uit te sluiten.
Bevestig dat de schema-sjablonen van versie 1 zijn bijgewerkt of buiten gebruik zijn gesteld in verband met ESC15 (CVE-2024-49019).
Controleer of de roltoewijzingen van CA-beheerder en certificaatmanager worden beoordeeld aan de hand van de administratieve interface van MS-CSRA.
Controleer of uw team heeft gemodelleerd wat het 47-daagse schema voor TLS-certificaten doet met het inschrijvingsvolume binnen deze protocolstack.

Eigenaar- en actiematrix per team

Het beveiligen van ADCS-protocollen mislukt het vaakst wanneer de verantwoordelijkheid onduidelijk is. Hieronder wordt beschreven hoe de verantwoordelijkheid binnen de PKI-, beveiligings-, platform- en compliance-teams verdeeld zou moeten worden.

Team	Primaire verantwoordelijkheid	Belangrijkste actie
PKI-team	Architectuur voor eigen protocolselectie en -inschrijving	Kies voor elke apparaatpopulatie het juiste inschrijvingstraject: MS-WCCE, MS-XCEP/MS-WSTEP of SCEP/NDES.
Beveiligingsteam	Eigen ESC-kwetsbaarheidsoplossing	Auditcertificatensjablonen tegen MS-CRTD en CA-configuratie tegen MS-CSRA voor ESC1 tot en met ESC15-condities
Platform- en DevOps-team	Automatisering van eigen inschrijvingen en beveiliging van eindpunten	Dwing HTTPS en EPA af op alle MS-WSTEP- en CES-eindpunten; automatiseer het beheer van de levenscyclus van certificaten.
Nalevingsteam	Eigen auditbewijs op protocolniveau	Gebruik inventaris- en levenscycluslogboeken op basis van MS-CSRA als bewijsmateriaal voor FIPS-, Common Criteria- en FedRAMP-beoordelingen.

ADCS-protocol beslissingstabel

Gebruik deze tabel om een situatie waarmee uw team te maken heeft, te koppelen aan de aanbevolen actie, de verantwoordelijke en het verwachte resultaat.

Use Case	Aanbeveling	Operationeel eigenaar	Verwacht resultaat
Certificaatsjablonen zijn niet gecontroleerd aan de hand van ESC1 tot en met ESC15.	Voer een audit op protocolniveau uit van de Subject Name, EKU en enrollment-agent-instellingen van elke template ten opzichte van MS-CRTD.	Beveiligingsteam	Mogelijke toegangsmogelijkheden worden geïdentificeerd en afgesloten voordat ze kunnen worden misbruikt.
Niet-domein- of externe apparaten hebben certificaten nodig.	Implementeer MS-XCEP en MS-WSTEP (CEP/CES) in plaats van de toegang tot MS-WCCE/RPC extern uit te breiden.	PKI-team	Certificaatinschrijving werkt zonder dat er extern RPC/DCOM-poorten geopend hoeven te worden.
Netwerkapparaten zoals routers, VPN-gateways en IoT-apparaten hebben certificaten nodig.	Implementeer NDES met SCEP in plaats van te proberen rechtstreeks ADCS te registreren.	Platform- en DevOps-team	Niet-Windows-apparaten kunnen zonder speciale tools worden geregistreerd.
Het oppervlak voor CA-toediening is niet beoordeeld.	Controleer het lidmaatschap van de CA-beheerder- en certificaatbeheerderrollen ten opzichte van de blootgestelde interfaces van MS-CSRA.	Beveiligingsteam	Beheer op afstand van CA's is beperkt tot accounts die dit daadwerkelijk nodig hebben.
Voorbereiding op de 47-daagse overstap naar TLS-certificaten	Het huidige inschrijvingsvolume voor MS-WCCE en MS-XCEP/MS-WSTEP wordt vergeleken met ongeveer acht keer de huidige frequentie.	PKI-team en platform-/DevOps-team gezamenlijk	De inschrijvingsinfrastructuur is correct gedimensioneerd vóór de deadline van maart 2029.

Wat te doen Volgende

PKI-teams: Breng alle momenteel gebruikte inschrijvingsroutes in kaart: MS-WCCE, MS-XCEP/MS-WSTEP en SCEP/NDES, en controleer of elke route geschikt is voor de betreffende apparatenpopulatie.
Beveiligingsteams: Voer dit kwartaal een ESC1 tot en met ESC15-audit uit op uw certificaatsjablonen (MS-CRTD) en CA-roltoewijzingen (MS-CSRA).
Platform- en DevOps-teams: Controleer of elk MS-WSTEP- en CES-eindpunt HTTPS en EPA afdwingt, en voer een proefproject uit met geautomatiseerd certificaatlevenscyclusbeheer.
Nalevingsteams: Controleer of uw op MS-CSRA gebaseerde audittrail al het bewijsmateriaal bevat waar uw volgende FIPS-, Common Criteria- of FedRAMP-audit om zal vragen.

Wat zijn Microsoft Open Specificaties?

In 2008 lanceerde Microsoft het Open Specifications- programma, een openbaar toegankelijke documentatiebibliotheek met gedetailleerde technische specificaties voor Windows-protocollen en -extensies. Het doel was om externe ontwikkelaars in staat te stellen clients en servers te bouwen die volledig interoperabel zijn met de producten van Microsoft.

De Open Specifications-bibliotheek bevat honderden documenten over Windows-protocollen, Microsoft Office-extensies en meer. Voor ADCS in het bijzonder vormen deze documenten de meest gezaghebbende en actief onderhouden technische referentie die beschikbaar is. In veel gevallen vervangen ze oudere TechNet-content die werd afgeschaft tijdens de overgang van Microsoft naar een uniform documentatieportaal rond 2015-2016.

Het ADCS Open Protocol-landschap

Het MS-CERSOD- document (Certificate Services Protocols Overview) dient als de centrale index voor alle ADCS-gerelateerde protocolspecificaties. Het organiseert de ADCS-functionaliteit in twee afzonderlijke groepen:

Protocollen voor certificaatinschrijving: Hoe klanten certificaten aanvragen, ontvangen en verlengen
CA-beheerprotocollen: Hoe beheerders de CA beheren en bedienen.

Protocollen voor certificaatinschrijving

1. MS-WCCE – Windows Client Certificate Enrollment Protocol

MS-WCCE is het fundamentele ADCS-inschrijvingsprotocol en het protocol dat het meest diep verankerd is in domein-gekoppelde Windows-omgevingen. Het definieert een reeks DCOM-interfaces (Distributed Component Object Model) waarmee een client rechtstreeks met een certificeringsinstantie kan communiceren om:

Nieuwe X.509-certificaten aanvragen
Vernieuw bestaande certificaten
CA-eigenschappen en -mogelijkheden ophalen
Informatie over de intrekking verkrijgen

Kernarchitectuur.

MS-WCCE is gebouwd op twee opeenvolgende DCOM-interfaces: ICertRequestD en ICertRequestD2. Deze interfaces bieden een eenvoudig aanvraag-antwoordmodel. De client dient een certificaatverzoek in (in PKCS #10-, CMC- of PKCS #7-formaat) en de CA reageert met een ondertekend certificaat of een gedetailleerde verklaring waarin wordt uitgelegd waarom het verzoek is geweigerd of in behandeling is genomen.

Vervoer.

MS-WCCE gebruikt RPC/DCOM via TCP. Dit betekent dat er netwerkverbinding met de CA nodig is via dynamische RPC-poorten en dat het inherent verbonden is aan het Active Directory-domeinlidmaatschap. De beleidsserver in een MS-WCCE-inschrijvingsscenario is altijd een domeincontroller.

Relevantie voor de veiligheid.

Omdat MS-WCCE gebruikmaakt van DCOM en Active Directory, vormt het een kwetsbaar punt voor diverse bekende technieken voor privilege-escalatie via Enterprise Security Certificates (ESC). Foutieve configuraties in certificaatsjablonen (sjabloon-ACL's, EKU-instellingen, machtigingen van de inschrijvingsagent) kunnen een aanvaller in staat stellen misbruik te maken van de MS-WCCE-workflow om certificaten te verkrijgen voor accounts met hoge privileges.

2. MS-ICPR – ICertPassage Remote Protocol

MS-ICPR is nauw verwant aan MS-WCCE en maakt ook gebruik van DCOM/RPC. Het biedt toegang tot de ICertPassage-interface, een eenvoudigere interface op een lager niveau die wordt gebruikt voor het rechtstreeks indienen van certificaatverzoeken bij een CA, zonder de uitgebreidere inschrijvingsfunctionaliteit die in MS-WCCE is ingebouwd.

MS-ICPR wordt voornamelijk gebruikt in scenario's voor programmatische certificaataanvragen en verschijnt als een apart DCOM-eindpunt op de certificeringsinstantie (CA). Het is ook relevant in scenario's voor certificaatrelay-aanvallen (zoals ESC8 en verwante technieken) omdat het een geauthenticeerd kanaal biedt voor het aanvragen van certificaten.

3. MS-XCEP – Protocol voor inschrijving voor het X.509-certificaat

MS-XCEP is het protocol dat de Certificate Enrollment Policy Web Service (CEP)-rol in ADCS mogelijk maakt. Hiermee kunnen clients informatie over het certificaatinschrijvingsbeleid ophalen via HTTP/HTTPS met behulp van SOAP-gebaseerde berichtenuitwisseling, zonder dat directe DCOM-verbinding met de CA nodig is.

Hoe het werkt.

De client stuurt een GetPolicies-verzoek naar het CEP-eindpunt. De server reageert met een GetPoliciesResponse die het volgende bevat: een verzameling objecten voor certificaatinschrijvingsbeleid die de beschikbare certificaatsjablonen beschrijven, een lijst met certificaatuitgevers (CES-servers) waarmee de client contact moet opnemen voor elk sjabloon, en de authenticatiemethode die voor elke uitgever moet worden gebruikt (Kerberos, gebruikersnaam/wachtwoord of certificaat).

Authenticatieopties.

Kerberos (voor apparaten die lid zijn van een domein)
Gebruikersnaam/wachtwoord (voor apparaten die geen deel uitmaken van een domein en authenticeren met domeinreferenties)
Certificaatgebaseerde authenticatie (wanneer de client al een geldig certificaat bezit)

4. MS-WSTEP – Web Services Trust Enrollment Protocol

Waar MS-XCEP de beleidsontdekking afhandelt , verzorgt MS-WSTEP de daadwerkelijke uitgifte van certificaten. Het vormt de basis van de Certificate Enrollment Web Service (CES)-rol in ADCS. Samen vormen MS-XCEP en MS-WSTEP de op webservices gebaseerde inschrijvingsstack die de RPC/DCOM-stack van MS-WCCE aanvult en in veel gevallen vervangt.

Protocolkenmerken.

Gebaseerd op WS-Trust (een WS-* beveiligingsstandaard), uitgebreid met Microsoft-specifieke mogelijkheden.
Communiceert via HTTPS met behulp van SOAP-berichten.
Ondersteunt certificaataanvragen in PKCS #10- en CMC-formaat.
Maakt end-to-end versleutelde certificaatregistratie mogelijk zonder blootstelling van RPC-poorten.

Veelvoorkomende implementatiescenario's.

Scenario	Gebruikt protocol	Transport	Rolservice
Windows-client die is aangesloten op een domein (on-premise)	MS-WCCE of MS-XCEP + MS-WSTEP	RPC/DCOM of HTTPS	CA / CES
Niet-domeinapparaat met domeinreferenties	MS-XCEP + MS-WSTEP	HTTPS/SOAP	CEP + CES
Certificaat verlengen via internet	MS-XCEP + MS-WSTEP (certificaatgebaseerde authenticatie)	HTTPS/SOAP	CEP + CES
Netwerkapparaatregistratie (NDES)	SCEP via HTTP/HTTPS	HTTP / HTTPS	NDES
Browsergebaseerde inschrijving	CAWE (Inschrijving via CA-webpagina)	HTTPS	CA Webinschrijving

Beveiligingswaarschuwing.

De webservicestack (MS-XCEP + MS-WSTEP) wordt doorgaans ingezet richting het internet of DMZ-segmenten. Een goede authenticatiebeveiliging, TLS-configuratie en netwerksegmentatie zijn cruciaal. ESC8-achtige relay-aanvallen kunnen ook HTTP-gebaseerde CES-eindpunten treffen als deze niet geconfigureerd zijn om HTTPS en Extended Protection for Authentication (EPA) te vereisen.

5. MS-CAESO – Protocol voor automatische certificaatinschrijving (gearchiveerd)

MS-CAESO was het oorspronkelijke protocol voor automatische certificaatregistratie in Windows-omgevingen: de automatische registratie en verlenging van certificaten voor domeingebruikers en -computers op basis van Groepsbeleid. Deze specificatie is gearchiveerd, omdat de kernfunctionaliteit ervan is opgenomen in de MS-WCCE- en MS-XCEP/MS-WSTEP-specificaties.

Kennis van MS-CAESO is nog steeds waardevol voor organisaties die oudere Windows-omgevingen gebruiken of legacy PKI-configuraties controleren.

Certificaatsjabloon en beleidsspecificaties

6. MS-CRTD – Beschrijving van certificaatsjablonen

Certificaatsjablonen vormen de kern van ADCS-implementaties binnen bedrijven. Ze definiëren welke certificaten kunnen worden uitgegeven, aan wie, onder welke voorwaarden en met welke sleutelgebruiksuitbreidingen. MS-CRTD specificeert de exacte structuur, kenmerken en codering van certificaatsjabloonobjecten zoals deze in Active Directory worden opgeslagen.

Wat MS-CRTD dekt.

Het schema van certificaatsjabloonobjecten in Active Directory (objectklasse, attribuutnamen, OID's)
Het coderen van Extended Key Usage (EKU)-beleid binnen sjablonen.
Uitgiftebeleid, instellingen voor onderwerpnamen, inschrijvingsrechten en beveiligingsbeschrijvingen
Verschillen in sjabloonschema's tussen versie 1, versie 2 en versie 3
De relatie tussen sjabloonkenmerken en de resulterende certificaatvelden.

Waarom dit belangrijk is voor de beveiliging.

Inzicht in MS-CRTD is essentieel voor het controleren van verkeerde configuraties van certificaatsjablonen – de hoofdoorzaak van de meeste ADCS-gerelateerde aanvallen waarbij privileges worden verhoogd (ESC1 tot en met ESC15). De recent ontdekte ESC15-kwetsbaarheid ( CVE-2024-49019 ) betrof specifiek de exploitatie van het gedrag van schema-sjablonen van versie 1, wat onderstreept waarom diepgaande kennis van MS-CRTD een beveiligingsvereiste is.

CA-administratieprotocollen

7. MS-CSRA – Protocol voor beheer op afstand van certificeringsdiensten

MS-CSRA definieert de DCOM-interfaces die worden gebruikt voor het op afstand beheren van een certificeringsinstantie. Het is het protocol achter de MMC-module voor certificeringsinstanties, het hulpprogramma certutil.exe en programmatisch beheer van certificeringsinstanties via Windows API's.

Administratieve werkzaamheden gedekt.

Het starten en stoppen van de CA-service
Het bekijken, goedkeuren, afwijzen en intrekken van lopende certificaataanvragen.
Beheer van de certificaatintrekkingslijst (CRL) en CRL-distributiepunten (CDP's)
CA-eigenschappen configureren (sleutelalgoritmen, CRL-schema's, auditinstellingen)
Het maken van een back-up en het herstellen van de CA-database.
De CA-database raadplegen voor uitgegeven, in behandeling zijnde, mislukte en ingetrokken certificaten.

MS-CSRA biedt toegang tot verschillende COM-interfaces, waaronder ICertAdmin, ICertAdmin2, ICertView, ICertView2 en IEnumCERTVIEWROW. Beheer van certificeringsinstanties op afstand via MS-CSRA vereist lidmaatschap van de rollen CA-beheerder of Certificaatmanager. Onjuist geconfigureerde CA-roltoewijzingen vormen een aanzienlijk risico op privilege-escalatie.

8. MS-OCSPA – Online Responder Administration Protocol

De Online Certificate Status Protocol (OCSP)-responder is een essentieel onderdeel van moderne PKI-infrastructuur. In plaats van dat clients grote CRL-bestanden moeten downloaden en verwerken, maakt OCSP realtime controle op intrekking van certificaten mogelijk met een eenvoudig verzoek-antwoordmechanisme.

MS-OCSPA definieert de DCOM-interfaces die worden gebruikt voor het beheren van de Microsoft OCSP-responder (de Online Responder-rolservice in ADCS), inclusief het configureren van OCSP-intrekkingsproviders, het beheren van OCSP-ondertekeningscertificaten en hun automatische verlenging, het bewaken van de status en cache van de OCSP-responder en het configureren van vernieuwingsintervallen voor intrekkingsgegevens.

Operationele beste praktijken.

OCSP-responders moeten worden geconfigureerd met speciale, kortstondige ondertekeningscertificaten (niet het CA-certificaat zelf).
OCSP-nieten Dit moet op webservers ingeschakeld worden om het OCSP-verkeer te verminderen en de prestaties te verbeteren.
Meerdere OCSP-responders achter een load balancer verbeteren de beschikbaarheid en elimineren single points of failure.

ADCS-inschrijving voorbij Open Specs: NDES/SCEP en moderne protocollen

Hoewel de Microsoft Open Specifications de native Windows-inschrijvingsprotocollen behandelen, ondersteunt ADCS ook inschrijving via het Simple Certificate Enrollment Protocol (SCEP) via de Network Device Enrollment Service (NDES)-rol.

NDES en SCEP

SCEP maakt het mogelijk voor netwerkapparaten – routers, switches, VPN-gateways, IoT-apparaten – die geen deel kunnen uitmaken van een Windows-domein om certificaten aan te vragen bij een ADCS CA. NDES fungeert als registratieautoriteit tussen het apparaat en de CA en valideert aanmeldingsverzoeken met behulp van een uitdagingswachtwoordmechanisme. SCEP is gedefinieerd in een IETF-standaard (RFC 8894) en wordt breed ondersteund door leveranciers van netwerkapparaten en MDM-platformen.

Wat ADCS niet standaard ondersteunt

ACME (RFC 8555): ADCS implementeert het ACME-protocol niet standaard. ACME is de standaard die door Let's Encrypt wordt gebruikt en die steeds vaker vereist is voor moderne DevOps- en cloud-native omgevingen. Oplossingen van derden kunnen ADCS koppelen aan ACME-compatibele clients.

EST (RFC 7030): Wordt niet standaard ondersteund in ADCS; EST is een moderner alternatief voor SCEP voor apparaten met beperkte mogelijkheden en wordt steeds vaker ingezet in combinatie met IoT PKI-programma's.

REST/JSON API: ADCS biedt geen eigen REST API. Interactie verloopt via DCOM, SOAP of de CryptoAPI/CertEnroll COM-interfaces.

Beveiligingsimplicaties van ADCS-open protocollen

Kennis van de ADCS-protocollaag is een beveiligingsvereiste geworden, en niet langer alleen een aandachtspunt voor ontwikkelaars. ESC-kwetsbaarheden zijn doorgedrongen tot het algemene beveiligingsbewustzijn, met ESC1, ESC2, ESC3, ESC6, ESC8 en ESC15 die gedocumenteerd en misbruikt worden. De onderstaande tabel koppelt elke kwetsbaarheid aan de bijbehorende protocollaag.

Deze risico's op protocolniveau worden versterkt door een breder probleem met de levenscyclus van certificaten. Uit DigiCert's Trust Pulse Survey, gepubliceerd op 2 juli 2025, bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met downtime als gevolg van certificaten, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat. Dit kan net zo goed veroorzaakt worden door een verkeerd geconfigureerde MS-WCCE-inschrijvingsprocedure of een te soepele MS-CRTD-sjabloon, bijvoorbeeld door een ongeplande intrekking of heruitgifte. Bron: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations.

Het voorstel SC-081v3 van het CA/Browser Forum, goedgekeurd op 11 april 2025, verlaagt de maximale geldigheidsduur van openbare TLS-certificaten naar 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Dit betekent een ruwe achtvoudige toename van de registratiefrequentie voor elk protocol in deze stack, precies de verschuiving naar TLS-certificaten met een geldigheidsduur van 47 dagen die MS-WCCE, MS-XCEP, MS-WSTEP en SCEP/NDES op grote schaal moeten ondersteunen. Bron: sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days . Uit het ITIC-rapport '2024 Hourly Cost of Downtime' blijkt dat de gemiddelde kosten van één uur downtime nu meer dan $ 300,000 bedragen voor meer dan 90% van de middelgrote en grote bedrijven. Dit onderstreept waarom een ESC-gerelateerd certificaatincident een bedrijfsrisico is, en niet alleen een beveiligingsrisico. Bron: itic-corp.com/itic-2024-hourly-cost-of-downtime-report.

Kwetsbaarheid	Protocollaag	Oorzaak	Notes
ESC1	MS-WCCE + MS-CRTD	Met dit sjabloon kan de aanvrager een willekeurige onderwerpnaam opgeven.	Grote impact; op grote schaal benut
ESC2	MS-WCCE + MS-CRTD	Het sjabloon heeft een EKU voor elk doel of geen EKU-beperking.	Breed potentieel voor misbruik van certificaten
ESC3	MS-WCCE + MS-CRTD	Misbruik van inschrijvingsagenten via Certificate Request Agent EKU	Tweefasige aanvalsketen
ESC6	MS-WCCE	De EDITF_ATTRIBUTESUBJECTALTNAME2-vlag is ingeschakeld op CA.	CA-niveau vlag, niet sjabloonniveau
ESC8	MS-WSTEP / HTTP CES	NTLM-doorgifte naar HTTP-gebaseerd CES-eindpunt	Relay-aanval; vereist HTTP (niet HTTPS)
ESC15	MS-CRTD (V1-sjablonen)	Willekeurige toepassingsbeleidsinjectie in V1-schemasjablonen	CVE-2024-49019; patch vereist

Praktische richtlijnen: Open specificaties gebruiken in uw PKI-programma

Voor PKI Architects

Gebruik MS-CERSOD als gezaghebbende referentie voor het ontwerpen van inschrijvingsarchitecturen, met name in hybride cloud of scenario's die gericht zijn op internet
Gebruik MS-XCEP + MS-WSTEP om inschrijvingsworkflows te ontwerpen voor apparaten die geen deel uitmaken van een domein, cloudworkloads en externe gebruikers.
Raadpleeg MS-CRTD bij het ontwerpen van nieuwe certificaatsjablonen om ervoor te zorgen dat de attribuutinstellingen overeenkomen met uw beoogde beveiligingsbeleid.

Voor beveiligingsingenieurs

Vergelijk uw ADCS-configuratie met MS-CRTD om verkeerde configuraties van sjabloonkenmerken te identificeren die overeenkomen met ESC-condities.
Controleer de roltoewijzingen van de CA's aan de hand van MS-CSRA om ervoor te zorgen dat het beheeroppervlak van de CA's minimaal wordt blootgesteld.
Zorg ervoor dat alle CES-eindpunten (MS-WSTEP) HTTPS en Extended Protection for Authentication (EPA) vereisen om relay-aanvallen te voorkomen.

Voor ontwikkelaars

Implementeer aangepaste inschrijvingsclients met behulp van de DCOM-interfaces die zijn gedefinieerd in MS-WCCE en MS-ICPR voor domeinomgevingen.
Gebruik de MS-XCEP + MS-WSTEP SOAP-interfaces voor platformonafhankelijke of webgebaseerde inschrijvingstoepassingen.
Raadpleeg MS-CSRA voor het bouwen van tools voor het monitoren, controleren of beheren van de levenscyclus van CA's.

Voor compliance- en auditteams

De open specificaties bieden bewijs op protocolniveau voor nalevingsverklaringen (FIPS, Common Criteria, FedRAMP) met betrekking tot hoe certificaten worden uitgegeven en beheerd
Gebruik de mogelijkheden van MS-CSRA om geautomatiseerde certificaatinventarisatie en levenscyclusbewaking op te zetten - essentieel voor auditgereedheid.

Hoe encryptieconsultancy kan helpen

Encryption Consulting is gespecialiseerd in PKI-strategie , ADCS-architectuur en certificaatlevenscyclusbeheer voor bedrijven en overheidsorganisaties. Of u nu voor het eerst ADCS implementeert, een verouderde PKI moderniseert, uw certificaatinfrastructuur beoordeelt op ESC-kwetsbaarheden of ADCS integreert met moderne DevOps-tools, ons team brengt diepgaande expertise op protocolniveau mee naar elk project.

Het beveiligen van ADCS-protocollen is een onderdeel van een breder programma voor cryptografische flexibiliteit. Ons CertSecure Manager- platform bouwt voort op hetzelfde werk op het gebied van certificaatdetectie en -inventarisatie dat nodig is om deze protocolstack te beveiligen. Ons PQC Center of Excellence en de PQC- gereedheidsbeoordelingen breiden diezelfde detectiediscipline uit naar de periode na de quantummigratie, en CBOM Secure zet dit om in een complete cryptografische materiaallijst. Raadpleeg onze handleiding over het omzetten van een CBOM-inventaris in bruikbare informatie om te zien hoe certificaatautomatisering, PQC-gereedheid en CBOM met elkaar verbonden zijn.

PKI-gezondheidsbeoordelingen: Audits op protocolniveau van uw ADCS-omgeving aan de hand van Microsoft Open Specifications en benchmarks voor beveiligingsversterking.
ADCS-architectuurontwerp: Ontwerp van de inschrijvingsstack (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), planning van de CA-hiërarchie en beheer van certificaatsjablonen.
Certificaatlevenscyclusbeheer: geautomatiseerde detectie, bewaking en verlenging van certificaten binnen uw gehele organisatie.
Beveiligingsversterking: Herstel van ESC-configuratiefouten, versterking van de CA-rol en optimalisatie van de CRL/OCSP-infrastructuur

Conclusie

De Microsoft Open Specifications for ADCS zijn veel meer dan alleen naslagwerk voor ontwikkelaars. Ze vormen de definitieve technische basis voor het begrijpen van hoe certificaten binnen uw organisatie worden aangevraagd, uitgegeven, beheerd en ingetrokken. Zoals het kwetsbaarheidslandschap van ESC duidelijk heeft gemaakt, leiden lacunes in de kennis op protocolniveau direct tot exploiteerbare beveiligingslekken.

Of u nu een nieuwe inschrijvingsarchitectuur ontwerpt, een bestaande CA-implementatie beveiligt, PKI-geïntegreerde tools bouwt of een beveiligingsbeoordeling uitvoert, beheersing van MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA en soortgelijke protocollen is niet langer optioneel. Een goed beheerde ADCS-omgeving is niet alleen een kwestie van de juiste configuratie. Het vereist een diepgaand begrip van de protocollen die elke interactie tussen clients, CA's en de door hen uitgegeven certificaten regelen. Investeren in die kennis is de meest betrouwbare manier om de bedreigingen voor de certificaatinfrastructuur van morgen voor te blijven.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit ADCS Open Protocols Specifications: A Complete Technical Guide?

De belangrijkste conclusie van deze handleiding is dat ADCS-beveiliging afhankelijk is van een goede beheersing van de protocollen: MS-WCCE en MS-ICPR regelen de inschrijving, MS-XCEP en MS-WSTEP zorgen voor de inschrijving van webservices, MS-CRTD definieert certificaatsjablonen en MS-CSRA en MS-OCSPA regelen het beheer van CA's en OCSP's. Vrijwel elke ESC-techniek voor privilege-escalatie is terug te voeren op een verkeerde configuratie op een van deze niveaus, meestal in certificaatsjablonen.

Waarom is dit belangrijk voor het beheer van de levenscyclus van bedrijfscertificaten?

Uit het Trust Pulse-onderzoek van DigiCert bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen, en dat 37.5% de oorzaak hiervan kon herleiden tot een verlopen certificaat. Een verkeerd geconfigureerde ADCS-protocollaag, een te ruime certificaatsjabloon of een kwetsbaar MS-WSTEP-eindpunt leidt tot hetzelfde resultaat: een ongeplande intrekking, heruitgifte of uitval. Dit is precies wat een gedisciplineerd certificaatlevenscyclusbeheer probeert te voorkomen.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

De PKI-teams zijn verantwoordelijk voor de protocolselectie en de architectuur voor de inschrijving. De beveiligingsteams zijn verantwoordelijk voor het controleren van certificaatsjablonen (MS-CRTD) en het beheer van certificeringsinstanties (MS-CSRA) voor ESC1 tot en met ESC15-condities. De platform- en DevOps-teams zijn verantwoordelijk voor het afdwingen van HTTPS en Extended Protection for Authentication op de inschrijvingspunten. De compliance-teams zijn verantwoordelijk voor het gebruik van MS-CSRA-gebaseerde audit trails als bewijsmateriaal voor FIPS-, Common Criteria- en FedRAMP-audits.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Zonder een audit op protocolniveau kunnen te ruime certificaatsjablonen (ESC1, ESC2, ESC3), een blootgestelde CA-vlag (ESC6), niet-gepatchte schema-sjablonen van versie 1 (ESC15) of een HTTP-only MS-WSTEP-eindpunt (ESC8) jarenlang onopgemerkt blijven. Elk van deze kwetsbaarheden vormt een gedocumenteerd, misbruikt pad voor privilege-escalatie binnen uw certificeringsinstantie.

Hoe vermindert automatisering het risico op certificaatuitval?

Door het automatiseren van certificaatdetectie en levenscyclusbeheer worden verkeerd geconfigureerde sjablonen, verlopen certificaten en niet-afdwingbare HTTPS- of EPA-instellingen aan het licht gebracht vóórdat ze een storing of een privilege-escalatie-incident veroorzaken, in plaats van nadat een ESC-techniek of een verlopen certificaat al is misbruikt.

Welke statistieken moeten teams bijhouden na de implementatie?

Houd het aantal certificaatsjablonen bij dat is gecontroleerd aan de hand van MS-CRTD voor ESC-voorwaarden, het percentage MS-WSTEP- en CES-eindpunten dat HTTPS en EPA afdwingt, de toewijzingen van CA-beheerrollen die zijn gecontroleerd aan de hand van MS-CSRA, en het aantal uitval- of incidentmeldingen met betrekking tot certificaten per kwartaal, vergeleken met uw basislijn van vóór de audit.

Hoe hangt dit samen met de 47-daagse TLS-certificaatgereedheid?

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Pas dezelfde sjabloonaudit (MS-CRTD), CA-beheerbeoordeling (MS-CSRA) en endpointbeveiliging (HTTPS en EPA op MS-WSTEP) consistent toe, ongeacht of de CA zich on-premises bevindt, in een hybride configuratie wordt gehost of gekoppeld is aan cloud-native inschrijving zoals SCEP/NDES voor netwerkapparaten, in plaats van één inschrijvingspad te beveiligen en een ander onbeveiligd te laten.

ADCS Open Protocols Specificaties: Een complete technische handleiding