IKEv2-sertifikaadi seadistamine iPhone'is: käsitsi või hallatav registreerimine
Registreerimistee määrab, millised sertifikaadivalikud olemas on. Valige esmalt käsitsi või hallatav ning seejärel sobitage serveri identiteet, kliendi mandaat ja algoritm.
RSA valimine seetõttu, et lüüsi sertifikaaditööriist kasutab seda vaikimisi, on otsus, mis tehakse enne olulist küsimust: kuidas need iPhone'id registreeritakse? Kasutaja sisestatud ühendus ja halduse poolt edastatud konfiguratsiooniprofiil pakuvad erinevaid seadeid ning mõned sertifikaadivalikud on olemas ainult ühel neist teedest. Kui järjekord on õige, jääb sertifikaadiplaan lühikeseks; kui see on vale, väljastate mandaadi, mida telefon ei kasuta. Käsitlege allolevaid samme järjestusena, sest igaüks kitsendab järgmise jaoks saadaolevaid valikuid.
Esimene samm: valige registreerimistee
Käsitsi seadistamine tähendab, et kasutaja sisestab serveri aadressi, valib autentimismeetodi ja esitab kõik mandaadid, mida liides lubab. Hallatav registreerimine tähendab, et profiil kannab aadressi, identifikaatoreid ja viidet mandaatide kandevormile. Hallatav tee suudab väljendada kombinatsioone, mida käsitsi ekraan ei suuda, ning seetõttu peab sertifikaadiotsus tulema pärast seda valikut, mitte enne.
Mõlemad teed suudavad telefoni autentida. Need erinevad selle poolest, mida saab seadistada, ja selle poolest, kellele identiteet kuulub, seega valige üks teadlikult, selle asemel et segada hallatavat profiili käsitsi mandaatide sisestamisega.
Teine samm: valige valitud tee jaoks algoritmid
Käsitsi seadistatud iPhone'ide puhul soovitavad strongSwan'i iOS-i koostalitlusmärkused RSA serverisertifikaati, sest käsitsi klient ei pruugi ECDSA serverisertifikaati aktsepteerida; samad märkused käsitlevad macOS-i eraldi. Lugege seda toetatud kliendikogumi juhisena, mitte püsiva seadusena Apple'i seadmete kohta. Hallataval profiilil on rohkem ruumi: see saab sertifikaaditüübi selgesõnaliselt valida, sealhulgas ECDSA kliendiidentiteedi, kui kandevorm ja lüüs mõlemad seda toetavad.
Enne millegi juurutamist valideerige iOS-i versioonid, mida te tegelikult toetate. Uusima versiooniga laboritelefon ei kirjelda seadmeparki, mis hõlmab vanemaid seadmeid, ja laboris töötav algoritm võib välitööl vanimal telefonil siiski ebaõnnestuda. Võtke versioonivahemik seadmehaldusest, mitte mälust. Kui seadmepark hõlmab mitut versiooni, testige esmalt kõige vanemat, sest just seal on käsitsi liides kõige piiravam.
Kolmas samm: lugege profiili välju eraldi asjadena
Mitmed sarnase nimega võtmed kirjeldavad erinevaid objekte. Kaugadress on host, millele telefon helistab. Kaugidentifikaator on IKE identiteet, mida see lüüsilt ootab. Kandevormi sertifikaadiviide osutab kliendimandaadile ning sertifikaaditüübi väli valib tüübi, mida kasutatakse IKEv2 masin-autentimiseks. Ükski neist ei ole CA allkirjaalgoritm, kuigi sõnad kattuvad.
Apple'i IKEv2 kandevormi viide loetleb RSA vaikimisi sertifikaaditüübina koos selgesõnaliste ECDSA variantidega ning seob väljaandja nime võtme kindlate autentimisseadetega. Lugege neid seoseid valitud meetodi viitest, selle asemel et kopeerida üks võti töötavast juurutusest.
Neljas samm: sobitage lüüsi identiteet selle sertifikaadiga
Kasutage selgesõnalist lüüsi nime, näiteks vpn.example.com ja pange vastav alternatiivne subjekti nimi serverisertifikaati. strongSwan'i Apple'i juhis eeldab ka serveri autentimise laiendatud võtmekasutust. RSA või ECDSA valimine ei muuda sellest midagi: algoritm ei suuda parandada nime mittevastavust, puuduvat EKU-d ega puudulikku ahelat.
Usaldusankru levitamine on identiteedi väitmisest eraldi ülesanne. Telefon vajab sertifikaadiahelat, mida see suudab valideerida, ja see tuleb seadistada ootama nime, mille te tegelikult sertifikaati panite.
See, et mõni muu platvorm edukalt ühendub, on tõend selle platvormi valideerimisreeglite kohta, mitte luba telefoni reegleid lõdvendada. Hoidke kontrollid klientide vahel ühesugused, kui teil pole dokumenteeritud põhjust erineda.
Viies samm: eraldage kliendi identiteet CA usaldusest
Kliendisertifikaat ja selle privaatvõti ei ole sama objekt kui CA sertifikaat, mida telefon usaldab. CA sertifikaadi pakkimine PKCS#12 identiteedi sisse ei paigalda seda automaatselt usaldusankruks igasse toetatud seadmesse, seega käsitlege usalduse levitamist omaette sammuna, millel on oma kontroll.
Kui disain kasutab selle asemel paroolipõhist EAP-d, vajab telefon ettenähtud kontoautentimist ja serveri valideerimist. See tee ei õigusta ühe jagatud kliendi privaatvõtme saatmist kogu seadmepargile, mis on teistsugune disain ja palju halvema rikkerežiimiga.
Lõpetage plaan uuendamist ja tühistamist silmas pidades: kes väljastab kliendimandaadi uuesti, kuidas profiili uuendatakse ja kuidas kadunud telefon ära lõigatakse. Registreerige profiili versioon ja seadmeversioonid, mille vastu valideerisite, sest see kirje teeb järgmisest sertifikaadivahetusest rutiinse muudatuse.