Rekisteröintimenetelmät

Siksi varmenteiden rekisteröintiprotokollien yksi keskeinen ominaisuus on se, miten ne todentavat varmennetta pyytävän osapuolen. Sen mukaan, mihin varmennetta käytetään, yksi tai toinen protokolla on edullisempi.

Toinen tärkeä ominaisuus on protokollan käytännön yleisyys. Rekisteröintimenetelmää tai -protokollaa on tuettava aiotussa käyttötapauksessa sekä CA:n että asiakaspään puolella.

Suosituimmat rekisteröintiprotokollat ovat:

• SCEP
• ACME
• EST
• Microsoftin RPC/DCOM
• Microsoftin SOAP
• Manuaalinen rekisteröinti CA:n verkkosivulla
• Muut valmistajakohtaiset protokollat

SCEP

Historia ja määrittely

Cisco kehitti alun perin Simple Certificate Enrollment Protocolin (SCEP). Vaikka standardia ei tuolloin ollut, protokolla yleistyi laajasti MDM-järjestelmissä. Cisco jatkoi vielä eteenpäin ja suunnitteli seuraajaprotokollan, Enrollment over Secure Transportin (EST), korvaamaan SCEPin. Siksi EST:stä tuli julkinen standardi RFC 7030:ssa paljon aiemmin kuin SCEPistä, joka standardoitiin RFC 8894:ssä huomattavasti myöhemmin, kun se oli jo vakiintunut MDM-järjestelmien varmennerekisteröinnin tosiasialliseksi standardiksi.

Tekniikka

SCEP perustuu HTTP:hen. SCEP-pyyntö on salattu ja allekirjoitettu PKCS#7, joka lähetetään SCEP-palveluun GET- tai POST-pyynnöllä. Palvelu vastaa SCEP-vastauksella, joka on jälleen salattu ja allekirjoitettu PKCS#7. Pyyntö sisältää PKCS#10 -varmennepyynnön, ja vastaus sisältää myönnetyn X.509-varmenteen.

Todennus

PKCS#10-pyyntö sisältää ”SCEP Challenge” -arvon, joka todentaa ja valtuuttaa allekirjoituspyynnön jollakin varsinaisen kanavan ulkopuolisella menetelmällä kulloisenkin SCEP-palvelun mukaan. Käytännössä käytössä on nykyään kolmenlaisia SCEP Challenge -arvoja:

Staattinen SCEP Challenge

Yksinkertaisin vaihtoehto on staattinen tunnuslause. Jos PKCS#10-pyynnön SCEP Challenge vastaa SCEP-palveluun tallennettua ennalta määritettyä arvoa, varmenne myönnetään, muussa tapauksessa pyyntö hylätään. Menetelmän ongelma on se, että käytännössä ei voida mitenkään tarkistaa, vastaavatko varmenteelle pyydetyt ominaisuudet pyytäjää. Tästä ongelmasta on olemassa jopa oma CVE.

Näitä menetelmiä voidaan eritellä tarkemmin:

1. Suorassa SCEP-rekisteröinnissä se taho, jolle varmenne on tarkoitus myöntää, viestii suoraan SCEP-palvelun kanssa. Esimerkiksi MDM-järjestelmä kehottaa jotakin Android-puhelinta tekemään SCEP-rekisteröinnin SCEP Challenge -arvolla ”SecurePassword”. Android-puhelin luo CSR:n, toivottavasti oikeilla arvoilla, ja lisää ”SecurePassword”-arvon SCEP Challengeksi. Sen jälkeen se lähettää CSR:n SCEP-palveluun ja saa vastauksena myönnetyn varmenteen.
2. Läpinäkyvä SCEP-välityspalvelin toimii aivan kuten HTTP:n käänteinen välityspalvelin. Koska SCEP on salattu ja allekirjoitettu, se ei tosiasiassa pysty katsomaan SCEP-pyyntöjen tai -vastausten sisään eikä muuttamaan niitä, mutta se voi ohjata verkkorajojen perusteella, kuka voi rekisteröidä varmenteita ja milloin.
3. Protokollasovittimena toimiva SCEP-välityspalvelin on järjestelmä, joka pyytää varmenteita SCEPin kautta jonkin toisen järjestelmän puolesta. Esimerkiksi JAMFin kaltainen MDM-järjestelmä voisi pyytää varmennetta SCEP-palvelusta jonkin iPhonen puolesta. Kun sillä on varmenne ja yksityinen avain, se voi jaella varmenteen jotakin toista protokollaa käyttäen. Näin vain MDM-järjestelmällä on pääsy SCEP Challenge -arvoon, ja se voi lisäksi hallita varmenteen sisältöä.

Dynaaminen SCEP Challenge

Tällöin kukin SCEP Challenge on voimassa vain yhtä varmennepyyntöä varten. Näin SCEP-palvelu voi tunnistaa SCEP-pyynnön ja varmistaa, että varmenteelle pyydetyt ominaisuudet vastaavat kyseiselle pyynnölle sallittuja.

Käytännössä on yleensä kaksi tapaa, joilla MDM-järjestelmä ja SCEP-CA voivat sopia pyynnössä käytettävästä SCEP Challenge -arvosta:

1. MDM-järjestelmä pyytää SCEP-palvelulta kertakoodin SCEP-pyyntöä varten, jos se tarvitsee sellaisen.
   1. Esimerkkinä on Microsoft NDES. NDESissä on erillinen hallintasivu, joka todennetaan AD-tunnuksilla. Jokaisella hallintasivun avauskerralla se luo ja näyttää uuden kertakoodin, jota voi käyttää yhteen SCEP-pyyntöön. Tässä kokoonpanossa NDES ei kuitenkaan tarkista varmenteen ominaisuuksia lainkaan, koska kertakoodi on yleinen.
2. MDM-järjestelmä luo kertakoodin silloin, kun se kehottaa hallittua järjestelmää pyytämään varmennetta SCEPin kautta. Kun SCEP-pyyntö saapuu SCEP-palveluun, palvelun on haettava kertakoodi MDM-järjestelmästä, yleensä web-koukun avulla, ja tarkistettava, vastaako se pyynnön SCEP Challenge -arvoa. Tälle protokollalle ei ole standardia, joten MDM-järjestelmän ja SCEP-palvelun on sovittava jostakin muodosta, ja toteutuksesta riippuu, tarkistetaanko pyynnön ominaisuuksia lainkaan.

Allekirjoitettu metatieto

SCEP Challenge -arvon pituutta ei käytännössä ole rajoitettu. Sen ei siis tarvitse olla ihmisen ymmärrettävissä oleva ”tunnuslause”, vaan se voi olla myös BLOB.

Intune käyttää SCEP Challenge -arvona allekirjoitettua ja salattua XML:ää. Se luo tämän XML:n palvelinpuolella ja lähettää sen asiakaslaitteelle, kun se haluaa rekisteröidä varmenteen ja luo SCEP-pyynnön.

SCEP-palvelun on lähetettävä koko PKCS#10-pyyntö Intunen SCEP Challenge -palveluun. SCEP Challenge -palvelulla on yksityinen avain XML:n purkamiseen ja julkinen avain sen tarkistamiseen, että sen on luonut aito Intune-palvelu.

XML sisältää pyyntöä koskevaa metatietoa, esimerkiksi sen, millainen Subject-kentän pitäisi olla. Tämä johdetaan toisaalta SCEP-määritysprofiilista ja toisaalta sen käyttäjän tai laitteen objektitiedoista, jolle varmenne on tarkoitus myöntää.

Esimerkiksi SCEP-määritysprofiilissa voi olla Subject-kentäksi määritetty CN={{DeviceId}}. Kun laite, jonka tunnus on xyz, pyytää varmennetta, XML kertoo, että Subject-kentän pitäisi olla CN=xyz. SCEP Challenge -palvelu vertaa sitten XML:n tietoja PKCS#10-pyynnön Subject-kenttään. Tarkistus epäonnistuu, jos Subject-kentät eroavat, ja onnistuu, jos tämä ja muut ominaisuudet täsmäävät.

SCEP-palvelu myöntää varmenteen vain, jos tarkistus onnistuu.

Microsoftilla on artikkeli, jossa tämä tarkistus selitetään.

Microsoft NDES tukee tätä erillisen NDES Policy Modulen avulla, muut SCEP-CA:t voivat tukea sitä natiivisti tai olla tukematta.

Microsoft RPC/DCOM

Historia

Microsoft Active Directory Certificate Services (ADCS), jota kutsutaan joskus pelkäksi ”Microsoft CA:ksi”, on Windows Serveriin sisäänrakennettu varmenneviranomaisohjelmisto. Ohjelmisto kehitettiin alun perin edellisen vuosituhannen lopulla, ja siihen tehtiin lisäyksiä seuraavien kymmenen tai viidentoista vuoden ajan.

Vaihtoehtoja ovat Microsoftin SOAP tai SCEP, joita Microsoft kutsuu nimillä Web Enrollment ja NDES.

Määrittely ja käyttöönotto

Meillä ei ole tiedossa muita CA-järjestelmiä, jotka toteuttaisivat tämän protokollan, vaikka Microsoft on sittemmin julkaissut määrittelyn Microsoft OpenSpecissä. Asiakaspäässä Windowsissa on sisäänrakennettu tuki protokollalle, muita alustoja ei tueta.

Tekniikka

Sen pääasiallinen rekisteröintimenetelmä on RPC:hen tai DCOMiin perustuva valmistajakohtainen protokolla.

Myös automaattinen rekisteröinti käyttää tätä protokollaa. Jotta automaattinen rekisteröinti toimisi, tarvitset

• toimialueeseen liitetyn laitteen.
• Ryhmäkäytäntö ottaa automaattisen rekisteröinnin käyttöön,
• Enterprise CA:n (erotuksena erillisestä CA:sta),
• joka rekisteröi varmennemallin, johon
• käyttäjällä tai laitteella on rekisteröinti- ja automaattisen rekisteröinnin oikeudet.

Automaattisten rekisteröintien oletustarkistusväli on 8 tuntia, joskin sen voi pakottaa komennolla certutil -pulse tai usein paremmin komennolla gpupdate -force.

Todennus

Tämä protokolla käyttää Active Directoryyn sisäänrakennettuja todennusprotokollia, eli käyttäjät ja tietokoneet todentautuvat AD-tunnuksillaan.