Pag-set up ng IKEv2 certificate sa iPhone: manual o pinamamahalaang pagpaparehistro

Ang pagpili ng RSA dahil ginagamit ito ng certificate tool ng gateway bilang default ay isang desisyong ginawa bago ang tanong na mahalaga: paano ipaparehistro ang mga iPhone na ito? Ang koneksyong tina-type mismo ng user at ang configuration profile na ibinibigay ng management ay nagpapakita ng magkaibang settings, at ang ilang pagpipilian sa certificate ay umiiral lamang sa isa sa mga landas na ito. Ayusin ang pagkakasunod-sunod at magiging maikli ang plano sa certificate; magkamali at maglalabas ka ng kredensyal na hindi gagamitin ng telepono. Ituring ang mga hakbang sa ibaba bilang isang sekwensya, dahil bawat isa ay nagpapaliit ng mga pagpipiliang available sa susunod.

Unang hakbang: piliin ang landas ng pagpaparehistro

Ang manual na setup ay nangangahulugan na ipinapasok ng user ang address ng server, pinipili ang paraan ng authentication at ibinibigay ang anumang kredensyal na pinapayagan ng interface. Ang pinamamahalaang pagpaparehistro ay nangangahulugan na ang profile ay nagdadala ng address, mga identifier at reference sa isang payload ng kredensyal. Ang pinamamahalaang landas ay makapagpapahayag ng mga kombinasyong hindi kayang gawin ng manual na screen, kaya ang desisyon sa certificate ay dapat dumating pagkatapos ng pagpiling ito, hindi bago.

Parehong landas ay makapagpapatunay ng telepono. Nagkakaiba sila sa kung ano ang maisasaayos at kung sino ang nagmamay-ari ng pagkakakilanlan, kaya pumili ng isa nang sinasadya sa halip na paghaluin ang pinamamahalaang profile sa manual na pagpasok ng kredensyal.

Ikalawang hakbang: piliin ang mga algorithm para sa landas na pinili mo

Para sa manual na naka-configure na iPhone, inirerekomenda ng strongSwan iOS interoperability notes ang RSA server certificate, dahil maaaring hindi tanggapin ng manual na kliyente ang ECDSA server certificate; ang parehong notes ay hiwalay na tinatrato ang macOS. Basahin ito bilang gabay para sa sinusuportahang set ng kliyente, hindi bilang permanenteng batas tungkol sa mga Apple device. Ang pinamamahalaang profile ay may mas maraming espasyo: maaari nitong tahasang piliin ang uri ng certificate, kasama ang ECDSA client identity, kapag parehong sinusuportahan ito ng payload at gateway.

I-validate ang mga bersyon ng iOS na talagang sinusuportahan mo bago mag-deploy ng kahit ano. Ang laboratory phone sa pinakabagong release ay hindi naglalarawan ng fleet na may kasamang mas lumang device, at ang algorithm na gumagana sa laboratory ay maaari pa ring mabigo sa pinakalumang telepono sa field. Kunin ang hanay ng bersyon mula sa device management, hindi sa memorya. Kung saklaw ng fleet ang maraming release, subukan muna ang pinakaluma, dahil doon pinaka-mahigpit ang manual na interface.

Ikatlong hakbang: basahin ang mga field ng profile bilang magkakahiwalay na bagay

Ilang key na magkapareho ang pangalan ay naglalarawan ng magkaibang object. Ang remote address ay ang host na tinatawagan ng telepono. Ang remote identifier ay ang IKE identity na inaasahang ipapakita ng gateway. Ang certificate reference sa payload ay tumutukoy sa isang kredensyal ng kliyente, at ang field ng uri ng certificate ay pumipili ng uri na ginagamit para sa IKEv2 machine authentication. Wala sa mga ito ang signature algorithm ng CA, kahit nagkakapatung-patong ang mga salita.

Inililista ng Apple IKEv2 payload reference ang RSA bilang default na uri ng certificate na may tahasang ECDSA variant, at iniuugnay ang issuer-name key sa partikular na authentication settings. Basahin ang mga ugnayang iyon sa reference ng paraang pinili mo sa halip na kopyahin ang isang key mula sa gumaganang deployment.

Ikaapat na hakbang: itugma ang pagkakakilanlan ng gateway sa certificate nito

Gumamit ng tahasang pangalan ng gateway, halimbawa vpn.example.com at ilagay ang katugmang alternatibong subject name sa server certificate. Inaasahan din ng strongSwan Apple guidance ang extended key usage para sa server authentication. Walang binabago ang pagpili ng RSA o ECDSA doon: hindi kayang ayusin ng algorithm ang hindi pagtutugma ng pangalan, nawawalang EKU o hindi kumpletong chain.

Ang pamamahagi ng trust anchor ay hiwalay na gawain sa paggigiit ng pagkakakilanlan. Kailangan ng telepono ang certificate chain na maaari nitong i-validate, at kailangang i-configure ito para asahan ang pangalang aktwal mong inilagay sa certificate.

Ang matagumpay na pagkonekta ng ibang platform ay ebidensya tungkol sa mga patakaran sa validation ng platform na iyon, hindi pahintulot na luwagan ang sa telepono. Panatilihing magkapareho ang mga pagsusuri sa mga kliyente maliban kung may dokumentadong dahilan para mag-iba.

Ikalimang hakbang: paghiwalayin ang pagkakakilanlan ng kliyente sa tiwala sa CA

Ang certificate ng kliyente at ang private key nito ay hindi parehong object ng CA certificate na pinagkakatiwalaan ng telepono. Ang pag-bundle ng CA certificate sa loob ng PKCS#12 identity ay hindi awtomatikong nag-i-install nito bilang trust anchor sa bawat sinusuportahang device, kaya ituring ang pamamahagi ng tiwala bilang sariling hakbang na may sariling verification.

Kung gumagamit ang disenyo ng EAP na nakabatay sa password sa halip, kailangan ng telepono ang inilaan na account authentication at server validation. Hindi binibigyang-katwiran ng landas na iyon ang pagpapadala ng isang shared client private key sa buong fleet, na ibang disenyo na may mas malubhang failure mode.

Tapusin ang plano na isinasaalang-alang ang renewal at revocation: sino ang muling naglalabas ng kredensyal ng kliyente, paano ina-update ang profile at paano pinuputol ang nawawalang telepono. Itala ang bersyon ng profile at ang mga bersyon ng device na ginamit mo sa validation, dahil ang rekord na iyon ang gumagawa sa susunod na pagpapalit ng certificate na isang routine na pagbabago.