Certifikat IKEv2 na iPhonu: ročna ali upravljana registracija

Izbira RSA samo zato, ker orodje za certifikate prehoda uporablja privzeto, je odločitev, sprejeta pred vprašanjem, ki je pomembno: kako bodo ti iPhoni registrirani? Povezava, ki jo uporabnik vnese sam, in konfiguracijski profil, ki ga zagotovi upravljanje, razkrivata različne nastavitve, in nekatere izbire certifikata obstajajo samo na eni od teh poti. Nastavite vrstni red pravilno in načrt certifikata postane kratek; zmotite se in izdate poverilnico, ki je telefon ne bo uporabil. Obravnavajte spodnje korake kot zaporedje, ker vsak zoži izbire, ki so na voljo naslednjemu.

Prvi korak: izberite pot registracije

Ročna nastavitev pomeni, da uporabnik vnese naslov strežnika, izbere metodo preverjanja pristnosti in zagotovi vse poverilnice, ki jih vmesnik dovoljuje. Upravljana registracija pomeni, da profil nosi naslov, identifikatorje in sklic na podatkovno obremenitev s poverilnicami. Upravljana pot lahko izrazi kombinacije, ki jih ročni zaslon ne more, zato mora odločitev o certifikatu priti po tej izbiri in ne pred njo.

Obe poti lahko preverita telefon. Razlikujeta se v tem, kaj je mogoče konfigurirati, in v tem, kdo ima identiteto, zato izberite eno zavestno, namesto da bi mešali upravljani profil z ročnim vnosom poverilnic.

Drugi korak: izberite algoritme za izbrano pot

Za ročno konfigurirane iPhone opombe strongSwan o interoperabilnosti z iOS priporočajo strežniški certifikat RSA, ker ročni odjemalec morda ne bo sprejel strežniškega certifikata ECDSA; iste opombe macOS obravnavajo ločeno. Berite to kot smernico za podprti nabor odjemalcev, ne kot trajni zakon o napravah Apple. Upravljani profil ima več prostora: lahko izrecno izbere vrsto certifikata, vključno z identiteto odjemalca ECDSA, ko to podpirata obremenitev in prehod.

Preden kar koli uvedete, preverite različice iOS, ki jih resnično podpirate. Laboratorijski telefon z najnovejšo različico ne opisuje skupine, ki vključuje starejše naprave, in algoritem, ki deluje v laboratoriju, lahko na najstarejšem telefonu na terenu vseeno odpove. Razpon različic vzemite iz upravljanja naprav, ne iz spomina. Če skupina zajema več različic, najprej preizkusite najstarejšo, ker je tam ročni vmesnik najbolj omejujoč.

Tretji korak: berite polja profila kot ločene stvari

Več podobno poimenovanih ključev opisuje različne objekte. Oddaljeni naslov je gostitelj, ki ga telefon kliče. Oddaljeni identifikator je identiteta IKE, ki jo telefon pričakuje od prehoda. Sklic na certifikat v obremenitvi kaže na poverilnico odjemalca, polje vrste certifikata pa izbere vrsto, ki se uporablja za strojno preverjanje pristnosti IKEv2. Nobeno od tega ni algoritam podpisa CA, čeprav se besede prekrivajo.

Applov sklic na obremenitev IKEv2 navaja RSA kot privzeto vrsto certifikata z izrecnimi različicami ECDSA in ključ imena izdajatelja povezuje z določenimi nastavitvami preverjanja pristnosti. Te odnose berite v sklicu za izbrano metodo, namesto da kopirate en ključ iz delujoče uvedbe.

Četrti korak: uskladite identiteto prehoda z njegovim certifikatom

Uporabite izrecno ime prehoda, na primer vpn.example.com in vstavite ustrezno nadomestno ime subjekta v strežniški certifikat. Smernice strongSwan za Apple pričakujejo tudi razširjeno uporabo ključa za preverjanje pristnosti strežnika. Izbira RSA ali ECDSA tega ne spremeni: algoritem ne more popraviti neujemanja imena, manjkajočega EKU ali nepopolne verige.

Razširjanje sidra zaupanja je ločena naloga od zatrjevanja identitete. Telefon potrebuje verigo certifikatov, ki jo lahko preveri, in mora biti konfiguriran tako, da pričakuje ime, ki ste ga resnično vstavili v certifikat.

Da se druga platforma uspešno poveže, je dokaz o pravilih preverjanja te platforme, ne dovoljenje za popuščanje pravil telefona. Vzdržujte preverjanja enaka med odjemalci, razen če imate dokumentiran razlog za razlikovanje.

Peti korak: ločite identiteto odjemalca od zaupanja v CA

Odjemalčev certifikat in njegov zasebni ključ nista isti objekt kot certifikat CA, ki mu telefon zaupa. Pakiranje certifikata CA v identiteto PKCS#12 ga ne namesti samodejno kot sidro zaupanja na vsaki podprti napravi, zato obravnavajte razširjanje zaupanja kot ločen korak z lastnim preverjanjem.

Če načrt namesto tega uporablja geslom podprt EAP, telefon potrebuje predvideno preverjanje pristnosti računa in preverjanje strežnika. Ta pot ne upravičuje pošiljanja enega skupnega zasebnega ključa odjemalca celotni skupini, kar je drugačen načrt z veliko slabšim načinom odpovedi.

Načrt zaključite z mislijo na obnovitev in preklic: kdo ponovno izda poverilnico odjemalca, kako se profil posodobi in kako se izgubljeni telefon odreže. Zabeležite različico profila in različice naprav, s katerimi ste preverjali, ker prav ta zapis naredi naslednjo zamenjavo certifikata rutinsko spremembo.