Innrulleringsmetoder

En kjerneegenskap ved protokoller for sertifikatinnrullering er derfor hvordan de autentiserer den som ber om sertifikatet. Avhengig av hva sertifikatet skal brukes til, er den ene eller den andre protokollen mest fordelaktig.

En annen viktig egenskap er hvor utbredt protokollen er i praksis. Innrulleringsmetoden eller protokollen må støttes både av CA-en og på klientsiden for det aktuelle bruksområdet.

De mest utbredte innrulleringsprotokollene er:

• SCEP
• ACME
• EST
• Microsoft RPC/DCOM
• Microsofts SOAP
• Manuell innrullering på nettsiden til CA-en
• Andre proprietære protokoller

SCEP

Historikk og spesifikasjon

Cisco var først ute med å finne opp Simple Certificate Enrollment Protocol (SCEP). Selv om det ikke fantes noen standard den gangen, ble protokollen svært utbredt i MDM-systemer. Cisco gikk til og med videre og utformet en etterfølger, Enrollment over Secure Transport (EST), som skulle erstatte SCEP. EST ble derfor en offentlig standard i RFC 7030 lenge før SCEP, som først ble standardisert i RFC 8894 mye senere, da den allerede var de facto-standarden for sertifikatinnrullering i MDM-systemer.

Teknologi

SCEP er HTTP-basert. En SCEP-forespørsel er en kryptert og signert PKCS#7 som sendes via en GET- eller POST-forespørsel til SCEP-tjenesten. Tjenesten svarer med et SCEP-svar, som igjen er en kryptert og signert PKCS#7. Forespørselen inneholder en PKCS#10-sertifikatsigneringsforespørsel, og svaret inneholder det utstedte X.509-sertifikatet.

Autentisering

PKCS#10-forespørselen inneholder en «SCEP Challenge» som autentiserer og autoriserer signeringsforespørselen gjennom en metode utenfor kanalen, avhengig av den konkrete SCEP-tjenesten. Det finnes tre typer SCEP-challenger i praktisk bruk i dag:

Statisk SCEP Challenge

Den enkleste muligheten er en statisk passfrase. Hvis SCEP-challengen i PKCS#10 stemmer med en forhåndsdefinert verdi som er lagret på SCEP-tjenesten, blir sertifikatet utstedt, ellers blir forespørselen avvist. Problemet med denne metoden er at det knapt er mulig å kontrollere om egenskapene det bes om i sertifikatet, faktisk passer til den som ber om det. Det finnes til og med en CVE for dette problemet.

Disse metodene kan deles ytterligere inn:

1. Ved en direkte SCEP-innrullering kommuniserer enheten som sertifikatet skal innrulleres til, direkte med SCEP-tjenesten. For eksempel kan et MDM-system be en Android-telefon om å gjøre en SCEP-innrullering med SCEP-challengen «SecurePassword». Android-telefonen genererer en CSR, forhåpentlig med riktige verdier, og legger til «SecurePassword» som SCEP-challenge. Deretter sender den CSR-en til SCEP-tjenesten og får det utstedte sertifikatet i retur.
2. En transparent SCEP-proxy fungerer akkurat som en omvendt HTTP-proxy. Fordi SCEP er kryptert og signert, kan den ikke se inn i SCEP-forespørslene eller SCEP-svarene, og heller ikke endre dem, men den kan styre hvem som får innrullere sertifikater og når, ut fra nettverksgrenser.
3. En protokolladapter-SCEP-proxy er et system som ber om sertifikater via SCEP på vegne av et annet system. Et MDM-system som JAMF kan for eksempel be en SCEP-tjeneste om et sertifikat på vegne av en iPhone. Når systemet har sertifikatet og den private nøkkelen, kan det rulle ut sertifikatet gjennom en annen protokoll. Slik er det bare MDM-systemet som har tilgang til SCEP-challengen, og det kan i tillegg styre innholdet i sertifikatet.

Dynamisk SCEP Challenge

Her er hver SCEP-challenge bare gyldig for én enkelt sertifikatforespørsel. Dermed kan SCEP-tjenesten identifisere SCEP-forespørselen og kontrollere at sertifikategenskapene det bes om, stemmer med det som er tillatt for nettopp den forespørselen.

I praksis brukes det stort sett to måter for at et MDM-system og en SCEP-CA skal bli enige om en SCEP-challenge for en forespørsel:

1. MDM-systemet ber SCEP-tjenesten om en engangskode for en SCEP-forespørsel når det trenger en.
   1. Et eksempel er Microsoft NDES. NDES har en egen administrasjonsside som autentiseres med AD-legitimasjon. Hver gang siden åpnes, opprettes og vises en ny engangskode som kan brukes til én enkelt SCEP-forespørsel. Brukt på denne måten kontrollerer NDES likevel ingen egenskaper ved sertifikatet, siden engangskoden er generisk.
2. MDM-systemet genererer en engangskode når det ber et administrert system om å be om et sertifikat via SCEP. Når SCEP-forespørselen kommer til SCEP-tjenesten, må tjenesten hente engangskoden fra MDM-systemet, vanligvis med en webhook, og kontrollere at den stemmer med SCEP-challengen i forespørselen. Det finnes ingen standard for denne protokollen, så MDM-systemet og SCEP-tjenesten må bli enige om et format, og det avhenger av implementeringen om egenskaper ved forespørselen i det hele tatt kontrolleres.

Signerte metadata

Det er i praksis ingen lengdebegrensning på SCEP-challengen. Den trenger derfor ikke å være en passfrase et menneske kan lese, den kan like gjerne være en BLOB.

Intune bruker en signert og kryptert XML som SCEP-challenge. Intune oppretter denne XML-en på serversiden og sender den til en klientenhet når enheten skal innrullere et sertifikat og opprette SCEP-forespørselen.

SCEP-tjenesten må sende hele PKCS#10-forespørselen til en Intune SCEP Challenge-tjeneste. SCEP Challenge-tjenesten har den private nøkkelen til å dekryptere XML-en og den offentlige nøkkelen til å kontrollere at den ble opprettet av en ekte Intune-tjeneste.

XML-en inneholder metadata om forespørselen, blant annet hvordan subjektet skal se ut. Dette utledes på den ene siden av SCEP-konfigurasjonsprofilen og på den andre siden av de konkrete objektdataene for brukeren eller enheten som sertifikatet skal utstedes til.

SCEP-konfigurasjonsprofilen kan for eksempel angi CN={{DeviceId}} som subjekt. Når enheten med ID-en xyz ber om et sertifikat, sier XML-en at subjektet skal være CN=xyz. SCEP Challenge-tjenesten sammenligner så opplysningene fra XML-en med subjektet i PKCS#10-forespørselen. Valideringen mislykkes hvis subjektene er forskjellige, og den lykkes hvis dette og de andre egenskapene stemmer.

SCEP-tjenesten utsteder bare sertifikatet hvis valideringen lykkes.

Microsoft har en artikkel som forklarer denne verifiseringen.

Microsoft NDES støtter dette med en ekstra NDES-policymodul, mens andre SCEP-CA-er kan ha eller mangle innebygd støtte for det.

Microsoft RPC/DCOM

Historikk

Microsoft Active Directory Certificate Services (ADCS), av og til bare kalt «Microsoft CA», er programvaren for sertifikatmyndighet som er innebygd i Windows Server. Programvaren ble opprinnelig utviklet mot slutten av forrige årtusen og fikk stadig noen tillegg de neste ti til femten årene.

Et alternativ er Microsofts SOAP eller SCEP, som Microsoft kaller henholdsvis Web Enrollment og NDES.

Spesifikasjon og utbredelse

Vi kjenner ikke til andre CA-systemer som implementerer denne protokollen, selv om Microsoft i mellomtiden har publisert spesifikasjonen i Microsoft OpenSpec. På klientsiden har Windows innebygd støtte for protokollen, andre plattformer støttes ikke.

Teknologi

Hovedmetoden for innrullering er en proprietær protokoll basert på RPC eller DCOM.

Automatisk innrullering bruker også denne protokollen. For at automatisk innrullering skal fungere, trenger du

• en domenetilknyttet enhet.
• Gruppepolicy må aktivere automatisk innrullering,
• en Enterprise CA (i motsetning til frittstående)
• som innrullerer en sertifikatmal der
• brukeren eller enheten har tillatelsene for innrullering og automatisk innrullering.

Standardintervallet for å se etter automatiske innrulleringer er 8 timer, men det kan tvinges fram med certutil -pulse eller ofte bedre med gpupdate -force.

Autentisering

Denne protokollen bruker autentiseringsprotokollene som er innebygd i Active Directory, det vil si at brukere og datamaskiner autentiserer seg med AD-legitimasjonen sin.