Registreringsmetoder

En central egenskap hos protokoll för certifikatregistrering är därför hur de autentiserar den som begär certifikatet. Beroende på vad certifikatet ska användas till är det ena eller det andra protokollet mer fördelaktigt.

Ytterligare en viktig egenskap är hur utbrett protokollet är i praktiken. Registreringsmetoden eller protokollet måste ha stöd både hos CA:n och på klientsidan för det avsedda användningsfallet.

De vanligaste registreringsprotokollen är:

• SCEP
• ACME
• EST
• Microsofts RPC/DCOM
• Microsofts SOAP
• Manuell registrering på CA:ns webbsida
• Andra proprietära protokoll

SCEP

Historik och specifikation

Det var Cisco som uppfann Simple Certificate Enrollment Protocol (SCEP). Trots att det inte fanns någon standard vid den tiden fick protokollet stor spridning i MDM-system. Cisco gick till och med vidare och tog fram ett efterföljande protokoll, Enrollment over Secure Transport (EST), som skulle ersätta SCEP. Därför blev EST en offentlig standard i RFC 7030 långt tidigare än SCEP, som standardiserades i RFC 8894 betydligt senare, när det redan var de facto-standard för certifikatregistrering i MDM-system.

Teknik

SCEP är HTTP-baserat. En SCEP Request är en krypterad och signerad PKCS#7 som skickas med en GET- eller POST-förfrågan till SCEP-tjänsten. Tjänsten svarar med en SCEP Response, återigen en krypterad och signerad PKCS#7. Förfrågan innehåller en certifikatsigneringsbegäran enligt PKCS#10, och svaret innehåller det utfärdade X.509-certifikatet.

Autentisering

PKCS#10-begäran innehåller en ”SCEP Challenge” som autentiserar och auktoriserar signeringsbegäran med någon out-of-band-metod, beroende på den specifika SCEP-tjänsten. I dag används tre sorters SCEP Challenge i praktiken:

Statisk SCEP Challenge

Det enklaste alternativet är en statisk lösenfras. Om SCEP Challenge i PKCS#10-begäran stämmer med ett fördefinierat värde som lagrats på SCEP-tjänsten utfärdas certifikatet, annars avvisas begäran. Problemet med metoden är att det knappt går att kontrollera om certifikatets begärda egenskaper stämmer överens med den som begär det. Det finns till och med en CVE för problemet.

Metoderna kan delas in ytterligare:

1. Vid en direkt SCEP-registrering kommunicerar den enhet som certifikatet ska registreras för direkt med SCEP-tjänsten. Ett MDM-system kan till exempel säga åt en Android-telefon att göra en SCEP-registrering med SCEP Challenge ”SecurePassword”. Android-telefonen genererar en CSR, förhoppningsvis med rätt värden, och lägger till ”SecurePassword” som SCEP Challenge. Sedan skickar den CSR:en till SCEP-tjänsten och får det utfärdade certifikatet i retur.
2. En transparent SCEP-proxy fungerar precis som en omvänd HTTP-proxy. Eftersom SCEP är krypterat och signerat kan den varken läsa eller ändra SCEP-förfrågningarna och svaren, men den kan styra vem som får registrera certifikat och när, utifrån nätverkets gränser.
3. En protokolladapterande SCEP-proxy är ett system som begär certifikat via SCEP åt ett annat system. Ett MDM-system som JAMF kan till exempel begära ett certifikat från en SCEP-tjänst åt en iPhone. När systemet har certifikatet och den privata nyckeln kan det distribuera certifikatet via ett annat protokoll. På så sätt är det bara MDM-systemet som har tillgång till SCEP Challenge, och det kan dessutom styra certifikatets innehåll.

Dynamisk SCEP Challenge

Här gäller varje SCEP Challenge bara för en enda certifikatbegäran. Det gör att SCEP-tjänsten kan identifiera SCEP-förfrågan och kontrollera att de begärda certifikategenskaperna stämmer med dem som är tillåtna för just den begäran.

I praktiken används i regel två sätt för ett MDM-system och en SCEP-CA att komma överens om vilken SCEP Challenge som ska användas för en begäran:

1. MDM-systemet begär en engångskod för en SCEP Request från SCEP-tjänsten när det behöver en.
   1. Ett exempel är Microsoft NDES. NDES har en separat ”admin”-sida som autentiseras med AD-uppgifter. Varje gång någon öppnar admin-sidan skapas och visas en ny engångskod som kan användas för en enda SCEP-förfrågan. I den här konfigurationen kontrollerar NDES dock inga egenskaper i certifikatet, eftersom engångskoden är generisk.
2. MDM-systemet genererar en engångskod när det säger åt ett hanterat system att begära ett certifikat via SCEP. När SCEP-förfrågan når SCEP-tjänsten måste tjänsten hämta engångskoden från MDM-systemet, vanligtvis med en webhook, och kontrollera om den stämmer med SCEP Challenge i förfrågan. Det finns ingen standard för det här protokollet, så MDM-systemet och SCEP-tjänsten måste enas om ett format, och det beror på implementeringen om några egenskaper i förfrågan kontrolleras.

Signerade metadata

Det finns i praktiken ingen längdbegränsning för SCEP Challenge. Den behöver alltså inte vara en ”lösenfras” som en människa kan läsa, utan kan lika gärna vara en BLOB.

Intune använder en signerad och krypterad XML som SCEP Challenge. Den skapas på serversidan och skickas till en klientenhet när ett certifikat ska registreras och SCEP Request skapas.

SCEP-tjänsten måste skicka hela PKCS#10-begäran till en Intune SCEP Challenge-tjänst. SCEP Challenge-tjänsten har den privata nyckeln för att dekryptera XML-filen och den publika nyckeln för att kontrollera att den skapades av en äkta Intune-tjänst.

XML-filen innehåller metadata om förfrågan, till exempel hur Subject ska se ut. Det härleds dels från SCEP-konfigurationsprofilen, dels från de specifika objektdata som hör till användaren eller enheten som certifikatet ska utfärdas för.

SCEP-konfigurationsprofilen kan till exempel ange CN={{DeviceId}} som subject. När enheten med id xyz begär ett certifikat anger XML-filen att subject ska vara CN=xyz. SCEP Challenge-tjänsten jämför sedan informationen från XML-filen med subject i PKCS#10-begäran. Valideringen misslyckas om de två skiljer sig åt, och den lyckas om detta och de övriga egenskaperna stämmer.

SCEP-tjänsten utfärdar certifikatet endast om valideringen lyckas.

Microsoft har en artikel som förklarar den här verifieringen.

Microsoft NDES stöder detta med en extra NDES Policy Module, medan andra SCEP-CA:er kan ha inbyggt stöd för det eller sakna det.

Microsoft RPC/DCOM

Historik

Microsoft Active Directory Certificate Services (ADCS), ibland bara kallat ”Microsoft CA”, är den programvara för certifikatutfärdare som är inbyggd i Windows Server. Programvaran utvecklades ursprungligen i slutet av förra millenniet och fick fortsatta tillägg under de följande tio till femton åren.

Ett alternativ är Microsofts SOAP eller SCEP, som Microsoft kallar Web Enrollment respektive NDES.

Specifikation och spridning

Vi känner inte till några andra CA-system som implementerar protokollet, även om Microsoft under tiden har publicerat specifikationen i Microsoft OpenSpec. På klientsidan har Windows inbyggt stöd för protokollet, medan andra plattformar inte stöds.

Teknik

Den huvudsakliga registreringsmetoden är ett proprietärt protokoll som bygger på RPC eller DCOM.

Autoenrollment använder också det här protokollet. För att autoenrollment ska fungera behöver du

• en domänansluten enhet.
• en grupprincip som aktiverar autoenrollment,
• en Enterprise CA (till skillnad från en fristående)
• som registrerar en Certificate Template där
• användaren eller enheten har behörigheterna enrollment och autoenrollment.

Standardintervallet för att söka efter autoenrollments är 8 timmar, men det går att framtvinga med certutil -pulse eller ofta hellre gpupdate -force.

Autentisering

Protokollet använder de autentiseringsprotokoll som är inbyggda i Active Directory, det vill säga användare och datorer autentiserar sig med sina AD-uppgifter.