IKEv2-sertifikaatinstelling op iPhone: handmatige versus bestuurde inskrywing

Om RSA te kies omdat die poort se sertifikaatgereedskap dit by verstek gebruik, is 'n besluit wat geneem word voordat die vraag wat saak maak beantwoord is: hoe gaan hierdie iPhones ingeskryf word? 'n Verbinding wat die gebruiker self intik en 'n konfigurasieprofiel wat deur bestuur afgelewer word, bied verskillende instellings, en sommige sertifikaatkeuses bestaan net op een van daardie roetes. Kry die volgorde reg, en die sertifikaatplan word kort; kry dit verkeerd, en jy reik 'n bewys uit wat die foon nie sal gebruik nie. Behandel die stappe hieronder as 'n reeks, want elkeen vernou die keuses wat vir die volgende beskikbaar is.

Stap een: kies die inskrywingsroete

Handmatige opstelling beteken die gebruiker tik die bedieneradres in, kies die verifikasiemetode en voer enige bewys in wat die koppelvlak toelaat. Bestuurde inskrywing beteken 'n profiel dra die adres, die identifiseerders en 'n verwysing na 'n bewysnuttelading. Die bestuurde roete kan kombinasies uitdruk wat die handmatige skerm nie kan nie, en daarom moet die sertifikaatbesluit ná hierdie keuse kom eerder as voor dit.

Beide roetes kan 'n foon verifieer. Hulle verskil in wat jy kan opstel en in wie die identiteit besit, so kies een doelbewus eerder as om 'n bestuurde profiel met handmatige bewysinvoer te meng.

Stap twee: kies algoritmes vir die roete wat jy gekies het

Vir handmatig opgestelde iPhones beveel strongSwan se iOS-versoenbaarheidsnotas 'n RSA-bedienercertifikaat aan, want die handmatige kliënt aanvaar dalk nie 'n ECDSA-bedienercertifikaat nie; dieselfde notas hanteer macOS afsonderlik. Lees dit as leiding vir die ondersteunde kliëntversameling eerder as 'n permanente wet oor Apple-toestelle. 'n Bestuurde profiel het meer ruimte: dit kan 'n sertifikaattipe eksplisiet kies, insluitend 'n ECDSA-kliëntidentiteit, wanneer die nuttelading en die poort dit albei ondersteun.

Valideer die iOS-weergawes wat jy werklik ondersteun voordat jy enigiets uitrol. 'n Laboratoriumfoon op die nuutste weergawe beskryf nie 'n vloot wat ouer toestelle insluit nie, en 'n algoritme wat in die laboratorium werk, kan steeds op die oudste foon in die veld misluk. Trek die weergaweverskeidenheid uit toestelbestuur eerder as uit jou geheue. As die vloot verskeie weergawes dek, toets die oudste een eerste, want dit is waar die handmatige koppelvlak die strengste is.

Stap drie: lees die profielvelde as afsonderlike dinge

Verskeie sleutels met amper dieselfde naam beskryf verskillende objekte. Die afgeleë adres is die gasheer wat die foon skakel. Die afgeleë identifiseerder is die IKE-identiteit wat dit verwag dat die poort voorhou. Die nuttelading se sertifikaatverwysing wys na 'n kliëntbewys, en die sertifikaattipe-veld kies die tipe wat vir IKEv2-masjienverifikasie gebruik word. Nie een daarvan is die CA se ondertekeningsalgoritme nie, al oorvleuel die woorde.

Apple se IKEv2-nutteladingverwysing lys RSA as die verstek sertifikaattipe met eksplisiete ECDSA-variante, en dit koppel die uitreikernaamsleutel aan bepaalde verifikasiestellings. Lees daardie verwantskappe uit die verwysing vir die metode wat jy gekies het, eerder as om een sleutel uit 'n werkende ontplooiing oor te neem.

Stap vier: laat die poort se identiteit by sy sertifikaat pas

Gebruik 'n eksplisiete poortnaam soos vpn.example.com en plaas 'n ooreenstemmende alternatiewe onderwerpnaam in die bedienercertifikaat. strongSwan se Apple-riglyne verwag ook die uitgebreide sleutelgebruik vir bedienerverifikasie. Om RSA of ECDSA te kies verander niks daaraan nie: 'n algoritme kan nie 'n naamwanverhouding, 'n ontbrekende EKU of 'n onvolledige ketting herstel nie.

Die verspreiding van die vertrouensanker is 'n aparte taak van die bevestiging van die identiteit. Die foon het 'n sertifikaatketting nodig wat dit kan valideer, en dit moet opgestel word om die naam te verwag wat jy werklik in die sertifikaat plaas.

Dat 'n ander platform suksesvol verbind, is bewyse oor daardie platform se valideringsreëls, nie toestemming om die foon se reëls te verslap nie. Hou die kontroles identies oor kliënte, tensy jy 'n gedokumenteerde rede het om te verskil.

Stap vyf: skei die kliëntidentiteit van die CA-vertroue

'n Kliëntsertifikaat en sy private sleutel is nie dieselfde objek as die CA-sertifikaat wat die foon vertrou nie. Om 'n CA-sertifikaat binne 'n PKCS#12-identiteit te bondel, installeer dit nie outomaties as 'n vertrouensanker op elke ondersteunde toestel nie, so behandel vertrouensverspreiding as sy eie stap met sy eie verifikasie.

As die ontwerp eerder wagwoordgebaseerde EAP gebruik, het die foon die bedoelde rekeningverifikasie plus bedienervalidasie nodig. Daardie roete regverdig nie die verspreiding van een gedeelde private kliëntsleutel aan die hele vloot nie, want dit is 'n ander ontwerp met 'n veel slegter foutmodus.

Voltooi die plan met hernuwing en herroeping in gedagte: wie die kliëntbewys heruitreik, hoe die profiel bygewerk word, en hoe 'n verlore foon afgesny word. Teken die profielweergawe en die toestelweergawes aan waarteen jy gevalideer het, want daardie rekord is wat die volgende sertifikaatoorrol 'n roetineverandering maak.