Rinktis RSA tik todėl, kad šliuzo sertifikatų įrankis jį naudoja pagal nutylėjimą, yra sprendimas, priimamas prieš svarbų klausimą: kaip šie iPhone bus registruojami? Vartotojo ranka įvestas ryšys ir valdymo pateiktas konfigūracijos profilis atskleidžia skirtingus nustatymus, o kai kurie sertifikato pasirinkimai egzistuoja tik viename iš šių kelių. Teisingai sudėliokite eiliškumą ir sertifikato planas taps trumpas; suklyskite ir išduosite prisijungimo duomenis, kurių telefonas nenaudos. Traktuokite toliau pateiktus veiksmus kaip seką, nes kiekvienas susiaurina kito veiksmo pasirinkimus.

Pirmas veiksmas: pasirinkite registravimo kelią

Rankinis nustatymas reiškia, kad vartotojas įveda serverio adresą, pasirenka autentifikavimo metodą ir pateikia bet kokius prisijungimo duomenis, kuriuos leidžia sąsaja. Valdomas registravimas reiškia, kad profilis neša adresą, identifikatorius ir nuorodą į prisijungimo duomenų turinį. Valdomas kelias gali išreikšti derinius, kurių rankinis ekranas negali, todėl sertifikato sprendimas turi ateiti po šio pasirinkimo, o ne prieš jį.

Abu keliai gali autentifikuoti telefoną. Jie skiriasi tuo, ką galima sukonfigūruoti, ir tuo, kam priklauso tapatybė, todėl sąmoningai pasirinkite vieną, o ne mastykite valdomą profilį su rankiniu prisijungimo duomenų įvedimu.

Antras veiksmas: pasirinkite algoritmus pasirinktam keliui

Rankiniu būdu sukonfigūruotiems iPhone, strongSwan iOS sąveikos pastabos rekomenduoja RSA serverio sertifikatą, nes rankinis klientas gali nepriimti ECDSA serverio sertifikato; tos pačios pastabos macOS nagrinėja atskirai. Skaitykite tai kaip palaikomo klientų rinkinio gairę, o ne kaip nuolatinį įstatymą apie Apple įrenginius. Valdomas profilis turi daugiau erdvės: jis gali aiškiai pasirinkti sertifikato tipą, įskaitant ECDSA kliento tapatybę, kai turinys ir šliuzas abu tai palaiko.

Prieš ką nors diegdami patikrinkite iOS versijas, kurias iš tikrųjų palaikote. Naujausios versijos laboratorinis telefonas neaprašo parko, kuriame yra senesnių įrenginių, o laboratorijoje veikiantis algoritmas vis tiek gali nepavykti seniausiame lauko telefone. Versijų diapazoną imkite iš įrenginių valdymo, o ne iš atminties. Jei parkas apima kelias versijas, pirmiausia išbandykite seniausią, nes ten rankinė sąsaja labiausiai riboja.

Trečias veiksmas: skaitykite profilio laukus kaip atskirus dalykus

Keli panašiai pavadinti raktai aprašo skirtingus objektus. Nuotolinis adresas yra prieglobos kompiuteris, į kurį telefonas skambina. Nuotolinis identifikatorius yra IKE tapatybė, kurią jis tikisi, kad šliuzas pateiks. Turinio sertifikato nuoroda nurodo kliento prisijungimo duomenis, o sertifikato tipo laukas pasirenka tipą, naudojamą IKEv2 mašinos autentifikavimui. Nė vienas iš jų nėra CA parašo algoritmas, nors žodžiai persidengia.

Apple IKEv2 turinio nuoroda nurodo RSA kaip numatytąjį sertifikato tipą su aiškiais ECDSA variantais ir sieja išdavėjo pavadinimo raktą su konkrečiais autentifikavimo nustatymais. Šiuos ryšius skaitykite pasirinkto metodo nuorodoje, o ne kopijuokite vieną raktą iš veikiančio diegimo.

Ketvirtas veiksmas: sulyginkite šliuzo tapatybę su jo sertifikatu

Naudokite aiškų šliuzo pavadinimą, pavyzdžiui vpn.example.com ir įdėkite atitinkantį alternatyvų subjekto pavadinimą į serverio sertifikatą. strongSwan Apple gairės taip pat tikisi išplėstinio rakto naudojimo serverio autentifikavimui. RSA ar ECDSA pasirinkimas nieko to nekeičia: algoritmas negali sutaisyti pavadinimo neatitikimo, trūkstamo EKU ar nepilnos grandinės.

Pasitikėjimo inkaro platinimas yra atskira užduotis nuo tapatybės deklaravimo. Telefonui reikia sertifikatų grandinės, kurią jis gali patikrinti, ir jis turi būti sukonfigūruotas laukti to pavadinimo, kurį iš tikrųjų įdėjote į sertifikatą.

Tai, kad kita platforma sėkmingai prisijungia, yra tos platformos tikrinimo taisyklių įrodymas, o ne leidimas atlaisvinti telefono taisykles. Laikykite patikras vienodas visiems klientams, nebent turite dokumentuotą priežastį skirtis.

Penktas veiksmas: atskirkite kliento tapatybę nuo CA pasitikėjimo

Kliento sertifikatas ir jo privatus raktas nėra tas pats objektas kaip CA sertifikatas, kuriuo telefonas pasitiki. CA sertifikato įpakavimas į PKCS#12 tapatybę neįdiegia jo automatiškai kaip pasitikėjimo inkaro kiekviename palaikomame įrenginyje, todėl pasitikėjimo platinimą traktuokite kaip atskirą veiksmą su savo patikra.

Jei dizainas vietoj to naudoja slaptažodžiu pagrįstą EAP, telefonui reikia numatytos paskyros autentifikavimo ir serverio patikros. Šis kelias nepateisina vieno bendro kliento privataus rakto siuntimo visam parkui, nes tai kitas dizainas su daug prastesniu gedimo režimu.

Užbaikite planą atsižvelgdami į atnaujinimą ir atšaukimą: kas iš naujo išduoda kliento prisijungimo duomenis, kaip atnaujinamas profilis ir kaip atjungiamas pamestas telefonas. Užrašykite profilio versiją ir įrenginių versijas, pagal kurias tikrinote, nes būtent šis įrašas daro kitą sertifikato keitimą įprastu darbu.

Susiję straipsniai