Sertipiko ng VPN sa Mac: bakit nananatiling walang laman ang tagapili ng pagkakakilanlan
Kailangan ng kliyente ang sertipiko kasama ang pribadong susi nito, sa imbakan na binabasa nito. Suriin muna ang pagkakakilanlan, pagkatapos kung tinatanggap ito ng gateway.
Ininstala mo ang sertipiko, lumilitaw ito sa Keychain Access na may madaling pangalan, at wala pa ring laman ang tagapili ng pagkakakilanlan ng kliyente ng VPN. Hindi naghahanap ng sertipiko ang kliyente. Naghahanap ito ng pagkakakilanlan: isang sertipikong katuwang ang pribadong susi na makapagpapatunay ng pagmamay-ari, nakaimbak kung saan pinapayagan ang kliyente na basahin ito.
Ang hinihingi ng kliyente ay pagkakakilanlan
Itinuturing ng balangkas ng seguridad ng Apple ang sertipiko at pagkakakilanlan bilang magkaibang bagay. Ang sertipiko ay pampublikong datos. Ang pagkakakilanlan ay ang sertipikong iyon kasama ang pribadong susi nito, at tanging ang pagkakakilanlan ang makakapagkumpleto ng hamon. Ang pinagkakatiwalaang sertipiko ng CA, sa kabilang banda, ay nagpapahintulot sa kliyente na suriin ang nagbigay; hindi nito ginagawang tagapagtaglay ng inilabas na kredensyal ng kliyente ang makina.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
Kaya hindi kailanman gumagawa ng magagamit na pagkakakilanlan ng kliyente ang pag-import ng file na .cer. Pampublikong materyal lamang ang laman ng file, at walang pagpapalit ng pangalan o pagtitiwala ang gagawa nitong pares ng susi.
Tatlong dahilan kung bakit nananatiling walang laman ang tagapili
Ang una ay kulang na pribadong susi, ibig sabihin ay wala itong ibinigay ng proseso ng pagpaparehistro o pag-import. Ang pangalawa ay imbakang hindi sinusuri ng kliyente: ang profile na may saklaw ng gumagamit ay tumitingin sa keychain ng gumagamit, at ang item na inilagay sa imbakan ng system ay maaaring hindi makita nito. Ang pangatlo ay hindi pagtutugma ng layunin o patakaran, kung saan umiiral ang sertipiko ngunit hindi wasto para sa pagpapatunay ng kliyente ayon sa mga tuntunin ng pag-deploy.
security find-identity -v -p ssl-clientInililista nito ang mga pagkakakilanlang itinuturing ng system na wasto para sa pagpapatunay ng kliyente. Kung zero ang bilang, ang problema ay nasa itaas ng kliyente ng VPN at walang pag-edit ng profile ang makakapag-ayos nito. Kung lumilitaw ang pagkakakilanlan dito ngunit wala sa kliyente, ang pagkakaiba ay nasa imbakan o saklaw ng kliyente.
Saan naninirahan ang pribadong susi, at sino ang makakagamit nito
Kapag nag-import ka ng pagkakakilanlan sa pamamagitan ng Keychain Access, nag-aalok ang dialog ng pag-import ng patutunguhang keychain. Alin ang tamang patutunguhan ay depende sa kliyente at sa kung ang profile ay may saklaw ng gumagamit o ng aparato. Ang lumang sagot na nagrerekomenda ng keychain ng system ay hindi pangkalahatang tuntunin, at ang pagkopya ng mga item sa pagitan ng mga imbakan ay hindi pagkukumpuni.
Ang System Roots ay isang koleksyon ng pagtitiwala. Ang paglalagay ng sertipiko doon ay nagbabago kung aling mga nagbigay ang pinagkakatiwalaan ng system; hindi ito gumagawa ng pribadong susi, at hindi ito imbakan ng pagkakakilanlan. Ang paglilipat ng mga walang kaugnayang sertipiko upang punuin ang tagapili ay ang uri ng pagkukumpuning nag-iiwan sa makina na may permanenteng pinalawak na hanay ng pagtitiwala.
Ang pag-access sa pribadong susi ay hiwalay na kontrol. Ang pagbibigay sa bawat aplikasyon ng pahintulot na gamitin ang susi ay lumulutas sa problema ng pagpili ng isang kliyente at nagbibigay ng parehong kakayahan sa lahat ng iba pa sa makina. Ibigay ito sa kliyenteng nangangailangan, at suriin kung ang susi ay sinusuportahan ng hardware o minarkahan bilang hindi maaaring i-export; kung oo, dapat gamitin ang sinusuportahang provider sa halip na na-export na kopya.
Paano itinuturo ng profile ang kredensyal
Sa pinamamahalaang native na configuration ng IKEv2, tinutukoy ng profile ang payload ng kredensyal nito sa pamamagitan ng PayloadCertificateUUID. Ang mahalaga ay ang tinukoy na pagkakakilanlan at ang paraan ng paghahanda nito; ang pag-edit ng display name sa profile ay hindi nag-aayos ng sangguniang tumuturo sa maling payload o sa isang hindi kailanman nagbigay ng susi.
Ang provider ng third party ay maaaring gumamit ng ganap na ibang mekanismo ng pagpili, tulad ng sariling imbakan nito o prompt ng system. Basahin ang dokumentasyon ng provider na iyon sa halip na ilipat ang mga palagay ng native na profile, at i-verify ang sanggunian sa profile na aktwal na naka-install, hindi sa draft sa console ng pamamahala.
Ang pagpili at pagtanggap ay magkaibang mga yugto
Ang punong tagapili ay nangangahulugang mahahanap at magagamit ng kliyente ang pagkakakilanlan. Wala itong sinasabi tungkol sa kung tatanggapin ito ng gateway. Sinusuri pa rin ng server ang nagbigay, ang window ng validity, ang status ng revocation at ang pagmamapa ng kredensyal na iyon sa isang account.
Subukan ang parehong yugto nang tahasan, sa ganoong pagkakasunod-sunod. Kumpirmahin na inaalok ang pagkakakilanlan, kumonekta, pagkatapos ay hilingin sa may-ari ng gateway na kumpirmahin kung aling kredensyal ang iniharap at aling tuntunin ng pagmamapa ang gumamit nito. Kung nag-aalok ang kliyente ng pagkakakilanlan at tinatanggihan ito ng server, ang natitirang trabaho ay nasa panig ng server. Ang muling pag-install ng sertipiko sa Mac ay hindi magbabago sa resultang iyon, gaano man karaming ulit itong gawin.