Enrollmentmethoden

Een kerneigenschap van enrollmentprotocollen voor certificaten is daarom hoe ze de aanvrager van een certificaat authenticeren. Afhankelijk van waarvoor het certificaat wordt gebruikt, is het ene of het andere protocol gunstiger.

Een andere belangrijke eigenschap is de verspreiding in de praktijk. De enrollmentmethode of het protocol moet voor het beoogde gebruiksscenario zowel door de CA als aan de clientzijde worden ondersteund.

De meest gebruikte enrollmentprotocollen zijn:

• SCEP
• ACME
• EST
• RPC/DCOM van Microsoft
• SOAP van Microsoft
• Handmatig enrollment op de webpagina van de CA
• Andere propriëtaire protocollen

SCEP

Geschiedenis en specificatie

Cisco bedacht het Simple Certificate Enrollment Protocol (SCEP) als eerste. Hoewel er destijds geen standaard bestond, raakte het breed verspreid in MDM-systemen. Cisco ging zelfs verder en ontwierp een opvolger, Enrollment over Secure Transport (EST), om SCEP te vervangen. EST werd daardoor veel eerder een publieke standaard, in RFC 7030, dan SCEP, dat pas veel later werd gestandaardiseerd in RFC 8894, toen het al de de-factostandaard was voor certificaatenrollment in MDM-systemen.

Technologie

SCEP is HTTP-gebaseerd. Een SCEP-request is een versleutelde en ondertekende PKCS#7 die via een GET- of POST-request naar de SCEP-service wordt gestuurd. De service antwoordt met een SCEP-response, opnieuw een versleutelde en ondertekende PKCS#7. Het request bevat een PKCS#10-certificaataanvraag, de response bevat het uitgegeven X.509-certificaat.

Authenticatie

Het PKCS#10-request bevat een “SCEP Challenge” die de ondertekeningsaanvraag authenticeert en autoriseert via een out-of-bandmethode, afhankelijk van de specifieke SCEP-service. In de praktijk worden vandaag drie soorten SCEP Challenges gebruikt:

Statische SCEP Challenge

De eenvoudigste variant is een statische wachtwoordzin. Komt de SCEP Challenge in de PKCS#10 overeen met een vooraf vastgelegde waarde op de SCEP-service, dan wordt het certificaat uitgegeven, anders wordt het request geweigerd. Het probleem met deze methode is dat vrijwel niet te controleren valt of de aangevraagde eigenschappen van het certificaat bij de aanvrager passen. Voor dit probleem bestaat zelfs een CVE.

Deze methoden zijn verder te onderscheiden:

1. Bij een direct SCEP-enrollment communiceert de entiteit waarvoor het certificaat wordt uitgegeven, rechtstreeks met de SCEP-service. Een MDM-systeem draagt bijvoorbeeld een Android-telefoon op om een SCEP-enrollment uit te voeren met de SCEP Challenge “SecurePassword”. De Android-telefoon genereert een CSR, hopelijk met de juiste waarden, en voegt “SecurePassword” toe als SCEP Challenge. Vervolgens stuurt hij de CSR naar de SCEP-service en ontvangt het uitgegeven certificaat terug.
2. Een transparante SCEP-proxy werkt net als een HTTP-reverseproxy. Omdat SCEP versleuteld en ondertekend is, kan die niet echt in de SCEP-requests of -responses kijken en ze ook niet wijzigen, maar wel op basis van netwerkgrenzen sturen wie wanneer certificaten mag aanvragen.
3. Een protocoladapter-SCEP-proxy is een systeem dat namens een ander systeem certificaten via SCEP aanvraagt. Een MDM-systeem als JAMF kan bijvoorbeeld namens een iPhone een certificaat aanvragen bij een SCEP-service. Zodra het het certificaat en de privésleutel heeft, kan het het certificaat via een ander protocol uitrollen. Zo heeft alleen het MDM-systeem toegang tot de SCEP Challenge en kan het ook de inhoud van het certificaat sturen.

Dynamische SCEP Challenge

In dit geval is elke SCEP Challenge maar geldig voor één enkele certificaataanvraag. Daardoor kan de SCEP-service het SCEP-request herkennen en verifiëren of de aangevraagde certificaateigenschappen overeenkomen met wat voor dat specifieke request is toegestaan.

In de praktijk zijn er doorgaans twee manieren waarop een MDM-systeem en een SCEP-CA een SCEP Challenge voor een request afspreken:

1. Het MDM-systeem vraagt bij de SCEP-service een eenmalige code aan voor een SCEP-request wanneer het er een nodig heeft.
   1. Een voorbeeld is Microsoft NDES. NDES heeft een aparte adminpagina die met AD-inloggegevens wordt geauthenticeerd. Bij elke toegang tot die pagina maakt en toont NDES een nieuwe eenmalige code die voor één SCEP-request kan worden gebruikt. In deze configuratie controleert NDES echter geen enkele eigenschap van het certificaat, omdat de eenmalige code generiek is.
2. Het MDM-systeem genereert een eenmalige code wanneer het een beheerd systeem opdraagt om via SCEP een certificaat aan te vragen. Komt het SCEP-request binnen bij de SCEP-service, dan moet die de eenmalige code bij het MDM-systeem ophalen, meestal via een webhook, en controleren of die overeenkomt met de SCEP Challenge in het request. Voor dit protocol bestaat geen standaard, dus moeten het MDM-systeem en de SCEP-service onderling een formaat afspreken, en het hangt van de implementatie af of eigenschappen van het request worden gecontroleerd.

Ondertekende metadata

Er geldt vrijwel geen lengtebeperking voor de SCEP Challenge. Het hoeft dus geen voor mensen leesbare “wachtwoordzin” te zijn, maar het kan ook een BLOB zijn.

Intune gebruikt een ondertekende en versleutelde XML als SCEP Challenge. Intune maakt die XML aan de serverkant en stuurt hem naar een clientapparaat wanneer het een certificaat wil laten uitgeven en het SCEP-request wil laten aanmaken.

De SCEP-service moet het volledige PKCS#10-request naar een Intune SCEP Challenge-service sturen. Die SCEP Challenge-service beschikt over de privésleutel om de XML te ontsleutelen en over de publieke sleutel om te controleren of die door een echte Intune-service is gemaakt.

De XML bevat metadata over het request, bijvoorbeeld hoe het Subject eruit hoort te zien. Dat wordt enerzijds afgeleid van het SCEP-configuratieprofiel en anderzijds van de specifieke objectgegevens van de gebruiker of het apparaat voor wie of waarvoor het certificaat moet worden uitgegeven.

Het SCEP-configuratieprofiel kan bijvoorbeeld CN={{DeviceId}} als subject instellen. Vraagt het apparaat met id xyz een certificaat aan, dan zegt de XML dat het subject CN=xyz moet zijn. De SCEP Challenge-service vergelijkt vervolgens de informatie uit de XML met het subject in het PKCS#10-request. De validatie mislukt als de subjects verschillen en slaagt als dit en de andere eigenschappen overeenkomen.

De SCEP-service geeft het certificaat alleen uit als de validatie slaagt.

Microsoft heeft een artikel waarin deze verificatie wordt uitgelegd.

Microsoft NDES ondersteunt dit met een aanvullende NDES-policymodule, andere SCEP-CA's ondersteunen dit al dan niet van huis uit.

Microsoft RPC/DCOM

Geschiedenis

Microsoft Active Directory Certificate Services (ADCS), soms alleen “Microsoft CA” genoemd, is de CA-software die in Windows Server is ingebouwd. De software werd oorspronkelijk aan het eind van het vorige millennium ontwikkeld en kreeg de tien tot vijftien jaar daarna nog enkele uitbreidingen.

Een alternatief is SOAP van Microsoft of SCEP, die Microsoft respectievelijk Web Enrollment en NDES noemt.

Specificatie en verspreiding

Voor zover wij weten implementeren geen andere CA-systemen dit protocol, hoewel Microsoft inmiddels de specificatie in Microsoft OpenSpec heeft gepubliceerd. Aan de clientzijde heeft Windows ingebouwde ondersteuning voor het protocol, andere platformen worden niet ondersteund.

Technologie

De belangrijkste enrollmentmethode is een propriëtair protocol op basis van RPC of DCOM.

Ook autoenrollment gebruikt dit protocol. Om autoenrollment te laten werken heb je nodig:

• een apparaat dat lid is van het domein.
• Group Policy die autoenrollment inschakelt,
• een Enterprise CA (in tegenstelling tot stand-alone)
• die een certificaatsjabloon uitgeeft waarvoor
• de gebruiker of het apparaat de rechten enroll en autoenroll heeft.

Standaard wordt er elke 8 uur op autoenrollments gecontroleerd, al kun je dat afdwingen met certutil -pulse of vaak beter met gpupdate -force.

Authenticatie

Dit protocol gebruikt de authenticatieprotocollen die in Active Directory zijn ingebouwd, dat wil zeggen dat gebruikers en computers zich authenticeren met hun AD-inloggegevens.