ADCS öppna protokollspecifikationer: En komplett teknisk guide

Active Directory-certifikattjänster (ADCS) är en av de mest använda Public Key Infrastructure (PKI)-lösningar i företagsvärlden. Medan de flesta organisationer interagerar med ADCS via Windows-gränssnittet eller PowerShell, är det protokolllagret under Microsofts publicerade öppna specifikationer som den verkliga tekniska historien finns. Att förstå dessa protokoll är avgörande för arkitekter, säkerhetsingenjörer, utvecklare som bygger PKI-integrerade verktyg och säkerhetsexperter som bedömer sårbarheter i certifikatinfrastruktur.

Den här guiden ger en omfattande, praktikerfokuserad genomgång av alla större ADCS Open Protocol-specifikationer, hur de relaterar till varandra och vad var och en betyder för din PKI-säkerhetssituation.

Vad är Microsofts Open-specifikationer?

År 2008 lanserade Microsoft Öppna specifikationer program, ett offentligt tillgängligt dokumentationsbibliotek som innehåller detaljerade tekniska specifikationer för Windows-protokoll och tillägg. Målet var att göra det möjligt för tredjepartsutvecklare att bygga klienter och servrar som är helt kompatibla med Microsofts produkter.

Open Specifications-biblioteket innehåller hundratals dokument som täcker Windows-protokoll, Microsoft Office-tillägg och mer. Specifikt för ADCS representerar dessa dokument den mest auktoritativa och aktivt underhållna tekniska referensen som finns tillgänglig, och ersätter i många fall äldre TechNet-innehåll som föråldrades under Microsofts övergång till en enhetlig dokumentportal runt 2015-2016.

ADCS öppna protokolllandskap

Ocuco-landskapet MS-CERSOD Dokumentet (Översikt över protokoll för certifikattjänster) fungerar som huvudindex för alla ADCS-relaterade protokollspecifikationer. Det organiserar ADCS-funktionalitet i två distinkta grupper:

• Protokoll för certifikatregistrering: Hur klienter begär, tar emot och förnyar certifikat
• Protokoll för CA-administration: Hur administratörer hanterar och driver CA:n

Protokoll för certifikatregistrering

1. MS-WCCE - Registreringsprotokoll för Windows-klientcertifikat

MS-WCCE är det grundläggande ADCS-registreringsprotokollet och det som är djupast inbäddat i domänanslutna Windows-miljöer. Det definierar en uppsättning DCOM-gränssnitt (Distributed Component Object Model) som gör det möjligt för en klient att kommunicera direkt med en Certifieringsmyndighet till:

• Begär nya X.509-certifikat
• Förnya befintliga certifikat
• Hämta CA-egenskaper och funktioner
• Hämta information om återkallelsestatus

Kärnarkitektur

MS-WCCE är byggt på två på varandra följande DCOM-gränssnitt: ICertRequestD och ICertRequestD2. Dessa gränssnitt erbjuder en enkel förfrågnings-svarsmodell. Klienten skickar in en certifikatbegäran (i PKCS #10-, CMC- eller PKCS #7-format) och certifikatutfärdaren svarar med antingen ett signerat certifikat eller en detaljerad förklaring som förklarar varför begäran nekades eller placerades i väntande status.

Johtin

MS-WCCE använder RPC/DCOM över TCP. Det betyder att det kräver nätverksanslutning till CA:n på dynamiska RPC-portar och är i sig kopplat till Active Directory-domänmedlemskap. Policyservern i ett MS-WCCE-registreringsscenario är alltid en domänkontrollant.

Säkerhetsrelevans

Eftersom MS-WCCE använder DCOM och Active Directory är det attackytan för flera välkända tekniker för eskalering av behörigheter för Enterprise Security Certificate (ESC). Felaktiga konfigurationer i certifikatmallar (mall-ACL:er, EKU-inställningar, behörigheter för registreringsagenter) kan göra det möjligt för en angripare att missbruka MS-WCCE-flödet för att få certifikat för konton med hög privilegier.

2. MS-ICPR -ICertPassage fjärrprotokoll

MS-ICPR är nära besläktat med MS-WCCE och använder även DCOM/RPC. Det exponerar ICertPassage-gränssnittet, ett enklare gränssnitt på lägre nivå som används för direkt inlämning av certifikatförfrågningar till en CA utan den mer omfattande registreringsintelligens som är inbyggd i MS-WCCE.

MS-ICPR används främst i scenarier med programmatiska certifikatförfrågningar och visas som en separat DCOM-slutpunkt på CA:n. Det är också relevant i scenarier med certifikatreläattacker (som ESC8 och relaterade tekniker) eftersom det tillhandahåller en autentiserad kanal för att begära certifikat.

3. MS-XCEP -X.509 certifikatregistreringspolicyprotokoll

MS-XCEP är protokollet som driver Webbtjänst för certifikatregistreringspolicy (CEP)-roll i ADCS. Den gör det möjligt för klienter att hämta information om certifikatregistreringspolicyer via HTTP/HTTPS med hjälp av SOAP-baserad meddelandehantering – utan att kräva direkt DCOM-anslutning till CA.

Hur det fungerar

Klienten skickar en GetPolicies-begäran till CEP-slutpunkten. Servern svarar med en GetPoliciesResponse som innehåller: en samling certifikatregistreringspolicyobjekt som beskriver tillgängliga certifikatmallar, en lista över certifikatutfärdare (CES-servrar) som klienten ska kontakta för varje mall och den autentiseringsmetod som ska användas för varje utfärdare (Kerberos, användarnamn/lösenord eller certifikat).

Autentiseringsalternativ

• Kerberos (för domänanslutna enheter)
• Användarnamn/lösenord (för enheter som inte tillhör domänen och autentiseras med domänuppgifter)
• Hämta CA-egenskaper och funktioner

4. MS-WSTEP - Registreringsprotokoll för förtroende för webbtjänster

Var MS-XCEP hanterar policyn Upptäckten, MS-WSTEP hanterar själva certifikatutfärdandet. Det driver Webbtjänst för certifikatregistrering (CES) roll i ADCS. Tillsammans bildar MS-XCEP och MS-WSTEP den webbtjänstbaserade registreringsstacken som kompletterar, och i många scenarier ersätter, RPC/DCOM-stacken som används av MS-WCCE.

Protokollegenskaper

• Baserat på WS-Trust (en WS-* säkerhetsstandard), utökat med Microsoft-specifika funktioner
• Kommunicerar via HTTPS med hjälp av SOAP-meddelanden
• Stöder certifikatförfrågningar i PKCS #10- och CMC-format
• Möjliggör registrering av krypterade certifikat från början till slut utan RPC-portexponering

Vanliga installationsscenarier

Scenario	Protokoll används	Johtin	Rolltjänst
Domänansluten Windows-klient (lokal)	MS-WCCE eller MS-XCEP + MS-WSTEP	RPC/DCOM eller HTTPS	CA / CES
Icke-domänenhet med domänuppgifter	MS-XCEP + MS-WSTEP	HTTPS/SOAP	CEP + CES
Certifikatförnyelse via internet	MS-XCEP + MS-WSTEP (certifikatbaserad autentisering)	HTTPS/SOAP	CEP + CES
Registrering av nätverksenhet (NDES)	SCEP över HTTP/HTTPS	HTTP / HTTPS	NDES
Webbläsarbaserad registrering	CAWE (CA Webbregistrering)	HTTPS	CA Webbregistrering

Säkerhetsanmärkning

Webbtjänststacken (MS-XCEP + MS-WSTEP) distribueras vanligtvis mot internet eller DMZ-segment. Korrekt autentiseringshärdning, TLS-konfiguration och nätverkssegmentering är avgörande. ESC8-liknande reläattacker kan också rikta sig mot HTTP-baserade CES-slutpunkter om de inte är konfigurerade för att kräva HTTPS och utökat skydd för autentisering (EPA).

5. MS-CAESO – Protokoll för automatisk registrering av certifikat (arkiverad)

MS-CAESO var det ursprungliga protokollet som styrde automatisk certifikatregistrering i Windows-miljöer - automatisk registrering och förnyelse av certifikat för domänanvändare och datorer baserat på grupprincip. Denna specifikation har arkiverats, eftersom dess kärnfunktionalitet har integrerats i specifikationerna MS-WCCE och MS-XCEP/MS-WSTEP.

Att förstå MS-CAESO är fortfarande värdefullt för organisationer som kör äldre Windows-miljöer eller granskar äldre PKI-konfigurationer.

Certifikatmall och policyspecifikationer

6. MS-CRTD – Beskrivning av certifikatmallar

Certifikatmallar är kärnan i ADCS-distributioner för företag. De definierar vilka certifikat som kan utfärdas, till vem, under vilka villkor och med vilka nyckelanvändningstillägg. MS-CRTD Anger den exakta strukturen, attributen och kodningen för certifikatmallobjekt som de lagras i Active Directory.

Vad MS-CRTD täcker

• Schemat för certifikatmallobjekt i Active Directory (objektklass, attributnamn, OID:er)
• Kodningen av EKU-policyer (Extended Key Usage) i mallar
• Utgivningspolicyer, inställningar för ämnesnamn, registreringsbehörigheter och säkerhetsbeskrivningar
• Skillnader mellan mallscheman för version 1 och version 2 och version 3
• Relationen mellan mallattribut och de resulterande certifikatfälten

Varför detta är viktigt för säkerheten

Att förstå MS-CRTD är grundläggande för granskning av felkonfigurationer av certifikatmallar – grundorsaken till de flesta ADCS-relaterade privilegieeskaleringsattacker (ESC1 till ESC15). Den nyligen avslöjade ESC15-sårbarheten (CVE-2024-49019) involverade specifikt utnyttjande av schemamallsbeteendet i version 1, vilket understryker varför djupgående kunskaper om MS-CRTD är en säkerhetsförutsättning.

CA-administrationsprotokoll

7. MS-CSRA - Protokoll för fjärradministration av certifikattjänster

MS-CSRA definierar DCOM-gränssnitten som används för att fjärradministrera en certifieringsutfärdare. Det är protokollet bakom MMC-snapin-modulen för certifieringsutfärdare, verktyget certutil.exe och programmatisk administration av certifikatutfärdare via Windows API:er.

Administrativ verksamhet som omfattas

• Starta och stoppa CA-tjänsten
• Visa, godkänna, neka och återkalla väntande certifikatförfrågningar
• Hantera lista över återkallade certifikat (CRL) och CRL-distributionspunkter (CDP:er)
• Konfigurera CA-egenskaper (nyckelalgoritmer, CRL-scheman, granskningsinställningar)
• Säkerhetskopiera och återställa CA-databasen
• Fråga efter utfärdade, väntande, misslyckade och återkallade certifikat i CA-databasen

MS-CSRA exponerar flera COM-gränssnitt, inklusive ICertAdmin, ICertAdmin2, ICertView, ICertView2 och IEnumCERTVIEWROW. Fjärradministration av CA via MS-CSRA kräver medlemskap i rollen CA-administratör eller Certifikatshanterare. Felkonfigurerade CA-rolltilldelningar utgör en betydande risk för eskalering av privilegier.

8. MS-OCSPA - Protokoll för administration av onlinesvarare

Ocuco-landskapet Online-certifikatstatusprotokoll (OCSP)-respondern är en nyckelkomponent i modern PKI-infrastruktur. Istället för att kräva att klienter laddar ner och analyserar stora CRL-filer, möjliggör OCSP kontroll av certifikatåterkallelse i realtid med en enkel mekanism för förfrågningssvar.

MS-OCSPA definierar DCOM-gränssnitten som används för att administrera Microsoft OCSP-respondern (rolltjänsten Online Responder i ADCS), inklusive konfigurering av OCSP-återkallningsleverantörer, hantering av OCSP-signeringscertifikat och deras automatiska förnyelse, övervakning av OCSP-responderns hälsa och cachestatus samt konfigurering av uppdateringsintervall för återkallningsdata.

Operativ bästa praxis

• OCSP-svarare bör konfigureras med dedikerade, kortlivade signeringscertifikat (inte själva CA-certifikatet)
• OCSP-häftning bör aktiveras på webbservrar för att minska OCSP-trafik och förbättra prestandan
• Flera OCSP-svarare bakom en lastbalanserare förbättrar tillgängligheten och eliminerar enskilda felpunkter

ADCS-registrering utöver öppna specifikationer: NDES/SCEP och moderna protokoll

Medan Microsoft Open Specifications täcker de inbyggda Windows-registreringsprotokollen, stöder ADCS även registrering via Enkelt certifikatregistreringsprotokoll (SCEP) via rollen Network Device Enrollment Service (NDES).

NDES och SCEP

SCEP gör det möjligt för nätverksenheter – routrar, switchar, VPN-gateways, IoT-enheter – som inte kan delta i en Windows-domän att begära certifikat från en ADCS CA. NDES fungerar som en registreringsauktoritet mellan enheten och CA:n och validerar registreringsförfrågningar med hjälp av en lösenordskontrollmekanism. SCEP definieras av en IETF-standard (RFC 8894) och stöds i stor utsträckning av leverantörer av nätverksenheter och MDM-plattformar.

Vad ADCS inte stöder nativt

ACME (RFC 8555): ADCS implementerar inte ACME-protokollet direkt. ACME är standarden som används av Let's Encrypt och krävs alltmer för moderna DevOps och molnbaserade miljöer. Tredjepartslösningar kan koppla samman ADCS med ACME-kompatibla klienter.

EST (RFC 7030): EST har inget nativt stöd i ADCS; det är ett modernare alternativ till SCEP för begränsade enheter och används i allt större utsträckning tillsammans med IoT PKI-program.

REST/JSON API: ADCS exponerar inget inbyggt REST API. Interaktion sker via DCOM, SOAP eller CryptoAPI/CertEnroll COM-gränssnitten.

Säkerhetskonsekvenser av ADCS öppna protokoll

Kunskap om ADCS-protokolllagret har blivit en säkerhetsförutsättning, inte bara en fråga för utvecklare. ESC-sårbarheter har blivit allt vanligare inom säkerhetsmedvetenheten, med ESC1, ESC2, ESC3, ESC6, ESC8 och ESC15 dokumenterade och beväpnade. Tabellen nedan mappar varje sårbarhet till sitt protokolllager.

Sårbarhet	Protokolllager	Grundorsak	Anmärkningar
ESC1	MS-WCCE + MS-CRTD	Mallen tillåter beställaren att ange godtyckligt ämnesnamn	Stor genomslagskraft; utnyttjas i stor utsträckning
ESC2	MS-WCCE + MS-CRTD	Mallen har EKU av något syfte eller ingen EKU-begränsning	Bred risk för missbruk av certifikat
ESC3	MS-WCCE + MS-CRTD	Missbruk av registreringsagent via certifikatförfrågningsagent EKU	Tvåstegs attackkedja
ESC6	MS-WCCE	EDITF_ATTRIBUTESUBJECTALTNAME2-flaggan aktiverad på CA	CA-nivåflagga, inte mallnivå
ESC8	MS-WSTEP / HTTP CES	NTLM-relä till HTTP-baserad CES-slutpunkt	Reläattack; kräver HTTP (inte HTTPS)
ESC15	MS-CRTD (V1-mallar)	Godtycklig applikationspolicyinjektion i V1-schemamallar	CVE-2024-49019; patch krävs

Praktisk vägledning: Använda öppna specifikationer i ditt PKI-program

För PKI Arkitekter

• Använd MS-CERSOD som auktoritativ referens för att utforma registreringsarkitekturer, särskilt i hybrid moln eller internetrelaterade scenarier
• Använd MS-XCEP + MS-WSTEP för att utforma registreringsflöden för enheter utanför domänen, molnarbetsbelastningar och fjärranvändare.
• Referera till MS-CRTD när du utformar nya certifikatmallar för att säkerställa att attributinställningarna matchar din avsedda säkerhetspolicy

För säkerhetsingenjörer

• Mappa din ADCS-konfiguration mot MS-CRTD för att identifiera felkonfigurationer av mallattribut som motsvarar ESC-villkor.
• Granska CA-rolltilldelningar mot MS-CSRA för att säkerställa att CA-administrationsytan är minimalt exponerad
• Säkerställ att alla CES-slutpunkter (MS-WSTEP) kräver HTTPS och utökat skydd för autentisering (EPA) för att förhindra reläattacker.

För utvecklare

• Implementera anpassade registreringsklienter med hjälp av DCOM-gränssnitten som definieras i MS-WCCE och MS-ICPR för domänmiljöer
• Använd MS-XCEP + MS-WSTEP SOAP-gränssnitt för plattformsoberoende eller webbaserade registreringsapplikationer
• Referera till MS-CSRA för att bygga verktyg för CA-övervakning, granskning eller livscykelhantering

För efterlevnads- och revisionsteam

• De öppna specifikationerna tillhandahåller bevis på protokollnivå för efterlevnadsintyg (FIPS, Common Criteria, FedRAMP) gällande hur certifikat utfärdas och hanteras
• Använd MS-CSRA-funktioner för att bygga automatiserad certifikatinventering och livscykelövervakning – avgörande för granskningsberedskap

Hur krypteringskonsulting kan hjälpa

Krypteringskonsulting specialiserar sig på PKI-strategi, ADCS-arkitektur och certifikatlivscykelhantering för företag och myndigheter. Oavsett om du distribuerar ADCS för första gången, moderniserar en äldre PKI, utvärderar din certifikatinfrastruktur för ESC-sårbarheter eller integrerar ADCS med moderna DevOps-verktyg, bidrar vårt team med djupgående expertis på protokollnivå till varje uppdrag.

• PKI-hälsobedömningar: Protokollnivågranskningar av din ADCS-miljö mot Microsoft Open Specifications och säkerhetsstandarder
• ADCS-arkitekturdesign: Design av registreringsstack (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), planering av CA-hierarki och styrning av certifikatmallar
• Hantering av certifikatlivscykel: Automatiserad identifiering, övervakning och förnyelse av certifikat i hela företaget
• Säkerhetshärdning: Åtgärdning av ESC-felkonfigurationer, härdning av CA-roller och optimering av CRL/OCSP-infrastruktur

Slutsats

Microsofts öppna specifikationer för ADCS är mycket mer än referensmaterial för utvecklare. De är den definitiva tekniska grunden för att förstå hur certifikat begärs, utfärdas, administreras och återkallas i hela företaget. Som sårbarhetslandskapet i ESC har tydligt visat, leder kunskapsluckor på protokollnivå direkt till utnyttjande av säkerhetsbrister.

Oavsett om du utformar en ny registreringsarkitektur, förstärker en befintlig CA-distribution, bygger PKI-integrerade verktyg eller genomför en säkerhetsbedömning, är det inte längre valfritt att kunna använda MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA och deras konkurrenter. En välstyrd ADCS-miljö handlar inte bara om korrekt konfiguration. Det kräver en djup förståelse för de protokoll som styr varje interaktion mellan klienter, CA:er och de certifikat de utfärdar. Att investera i den kunskapen idag är det mest tillförlitliga sättet att ligga steget före morgondagens hot mot certifikatinfrastrukturen.