Certifikata IKEv2 në iPhone: regjistrim manual ose i menaxhuar

Zgjedhja e RSA vetëm sepse mjeti i certifikatave i portës e përdor si parazgjedhje është një vendim i marrë para pyetjes që ka rëndësi: si do të regjistrohen këto iPhone? Një lidhje e shtypur nga vetë përdoruesi dhe një profil konfigurimi i dorëzuar nga menaxhimi ekspozojnë cilësime të ndryshme, dhe disa zgjedhje certifikate ekzistojnë vetëm në njërën prej këtyre rrugëve. Vendoseni rendin drejt dhe plani i certifikatës bëhet i shkurtër; gaboni dhe do të lëshoni një kredencial që telefoni nuk do ta përdorë. Trajtojini hapat më poshtë si një sekuencë, sepse secili ngushton zgjedhjet e disponueshme për hapin tjetër.

Hapi i parë: zgjidhni rrugën e regjistrimit

Konfigurimi manual do të thotë që përdoruesi fut adresën e serverit, zgjedh metodën e vërtetimit dhe siguron çdo kredencial që lejon ndërfaqja. Regjistrimi i menaxhuar do të thotë që një profil mban adresën, identifikuesit dhe një referencë për një ngarkesë kredencialesh. Rruga e menaxhuar mund të shprehë kombinime që ekrani manual nuk mundet, prandaj vendimi për certifikatën duhet të vijë pas kësaj zgjedhjeje dhe jo para saj.

Të dyja rrugët mund të vërtetojnë një telefon. Ato ndryshojnë në atë që mund të konfigurohet dhe në kë zotëron identitetin, prandaj zgjidhni një me vetëdije në vend që të përzieni një profil të menaxhuar me futje manuale të kredencialeve.

Hapi i dytë: zgjidhni algoritmet për rrugën që zgjodhët

Për iPhone-t e konfiguruar manualisht, shënimet e strongSwan për ndërveprimin me iOS rekomandojnë një certifikatë serveri RSA, sepse klienti manual mund të mos pranojë një certifikatë serveri ECDSA; të njëjtat shënime e trajtojnë macOS veçmas. Lexojeni këtë si udhëzim për grupin e klientëve të mbështetur, jo si ligj të përhershëm për pajisjet Apple. Një profil i menaxhuar ka më shumë hapësirë: mund të zgjedhë në mënyrë të qartë një lloj certifikate, përfshirë një identitet klienti ECDSA, kur ngarkesa dhe porta e mbështesin të dyja.

Vërtetoni versionet e iOS që vërtet mbështesni përpara se të vendosni ndonjë gjë. Një telefon laboratori në versionin më të ri nuk përshkruan një flotë që përfshin pajisje më të vjetra, dhe një algoritëm që funksionon në laborator mund të dështojë gjithsesi në telefonin më të vjetër në terren. Merrni intervalin e versioneve nga menaxhimi i pajisjeve dhe jo nga kujtesa. Nëse flota përfshin disa versione, provoni së pari atë më të vjetrin, sepse atje ndërfaqja manuale është më kufizuese.

Hapi i tretë: lexoni fushat e profilit si gjëra të veçanta

Disa çelësa me emra të ngjashëm përshkruajnë objekte të ndryshme. Adresa e largët është hosti që telefoni thërret. Identifikuesi i largët është identiteti IKE që pritet të paraqesë porta. Referenca e certifikatës në ngarkesë tregon një kredencial klienti, dhe fusha e llojit të certifikatës zgjedh llojin e përdorur për vërtetimin e makinës IKEv2. Asnjë prej tyre nuk është algoritmi i nënshkrimit të CA-së, edhe pse fjalët mbivendosen.

Referenca e ngarkesës IKEv2 e Apple rendit RSA si llojin e parazgjedhur të certifikatës me variante të qarta ECDSA, dhe lidh çelësin e emrit të lëshuesit me cilësime të caktuara vërtetimi. Lexojini ato marrëdhënie në referencën për metodën që zgjodhët, në vend që të kopjoni një çelës nga një vendosje që funksionon.

Hapi i katërt: përputhni identitetin e portës me certifikatën e saj

Përdorni një emër të qartë porte, për shembull vpn.example.com dhe vendosni një emër alternativ subjekti që përputhet në certifikatën e serverit. Udhëzimi Apple i strongSwan pret gjithashtu përdorimin e zgjeruar të çelësit për vërtetimin e serverit. Zgjedhja e RSA ose ECDSA nuk ndryshon asgjë nga kjo: një algoritëm nuk mund të rregullojë një mospërputhje emri, një EKU që mungon ose një zinxhir të paplotë.

Shpërndarja e spirancës së besimit është detyrë e veçantë nga pohimi i identitetit. Telefoni ka nevojë për një zinxhir certifikatash që mund ta vërtetojë, dhe duhet të konfigurohet të presë emrin që keni vendosur në të vërtetë në certifikatë.

Fakti që një platformë tjetër lidhet me sukses është provë për rregullat e vërtetimit të asaj platforme, jo leje për të zbutur rregullat e telefonit. Mbani kontrollet identike midis klientëve, përveç nëse keni një arsye të dokumentuar për t'u diferencuar.

Hapi i pestë: ndani identitetin e klientit nga besimi në CA

Një certifikatë klienti dhe çelësi i saj privat nuk janë i njëjti objekt si certifikata CA të cilën telefoni i beson. Paketimi i një certifikate CA brenda një identiteti PKCS#12 nuk e instalon automatikisht si spirancë besimi në çdo pajisje të mbështetur, prandaj trajtojeni shpërndarjen e besimit si hap më vete me verifikimin e vet.

Nëse dizajni përdor në vend të kësaj EAP të bazuar në fjalëkalim, telefoni ka nevojë për vërtetimin e synuar të llogarisë plus verifikimin e serverit. Kjo rrugë nuk justifikon dërgimin e një çelësi privat të përbashkët klienti për të gjithë flotën, që është një dizajn tjetër me një mënyrë dështimi shumë më të keqe.

Përfundoni planin duke pasur parasysh rinovimin dhe revokimin: kush e lëshon përsëri kredencialin e klientit, si përditësohet profili dhe si ndërpritet një telefon i humbur. Regjistroni versionin e profilit dhe versionet e pajisjeve me të cilat vërtetuat, sepse ai regjistrim është ai që e bën ndryshimin e radhës të certifikatës një ndryshim rutinë.