Pag-login sa VPN gamit ang sertipiko sa Mac: pagkakakilanlan, paggamit ng susi o pagtitiwala sa gateway?

Ang mga pag-login sa VPN na nakabatay sa sertipiko ay humihingi sa Mac ng mas makitid kaysa sa password: gamitin ang partikular na pribadong susi na ito, sa kontekstong ito ng pagpapatupad, upang patunayan ang pagkakakilanlan sa gateway na iyon. Kapag nabigo, kadalasang inilalarawan ng mensahe ang huling bagay na nagkamali, at bihira iyon ang dahilan. Ang pagdaan sa tatlong desisyon sa pagkakasunod-sunod na ginagawa ng sistema ay nagpapanatili ng tapat na pagsusuri, at pumipigil sa isang lokal na suliranin sa pahintulot na ituring na kabiguan sa pagpapatunay ng kadena.

Daigin ang pag-login sa pagkakasunod-sunod na ginagawa ng Mac

Una pumipili ang kliyente ng pagkakakilanlan: isang sertipikong ipinares sa magagamit na pribadong susi, na makukuha sa pamamagitan ng sinusuportahang imbakan o tagapagbigay ng kredensyal. Pagkatapos hinihiling ng bahagi ng VPN na magsagawa ng kriptograpikong operasyon gamit ang susi, at sumasagot ang lokal na modelo ng awtorisasyon. Pagkatapos lamang na magtagumpay ang dalawa nagaganap ang pakikipagkamay sa malayo, kung saan sinusuri ng Mac ang gateway at sinusuri ng gateway ang patunay ng kliyente.

Basahin ang talahanayan mula itaas pababa at huminto sa unang hilera na nabigo. Lahat ng nasa ilalim ng kabiguan ay hindi napatunayan, kaya ang “hindi pinagkakatiwalaan ang sertipiko” ay isang napakakaraniwan at napakaduda na konklusyon.

Ano ang aktwal na sinasaklaw ng lokal na pahintulot

Sa modelo ng keychain ng macOS, ang mga protektadong item ay nagtataglay ng mga tuntunin sa pag-access na partikular sa operasyon at isang listahan ng pinagkakatiwalaang aplikasyon. Ang pagpirma gamit ang pribadong susi ay isa sa mga operasyong iyon, at ang mga tuntunin ay nalalapat sa executable na gumagawa nito, hindi sa sertipiko bilang dokumento. Ang sanggunian ng Apple sa pagkontrol ng access ay gumuguhit din ng linya sa pagitan ng modelong ito at ng keychain ng iCloud at ng mga kaayusan ng pangkat ng access, kaya ang payong isinulat para sa isa ay hindi lumilipat sa isa pa.

Dalawang bunga ang sumusunod. Ang isang pampublikong sertipikong nakikita sa isang listahan ay hindi nagpapatunay na ang bahagi sa likuran ng VPN ay maaaring makarating sa susi. At ang pahintulot na ibinigay sa isang aplikasyong pangharap ay walang sinasabi tungkol sa hiwalay na katulong o extension ng network, dahil magkaibang code ang mga ito na may magkaibang pagkakakilanlan.

Kilalanin ang aktwal na implementasyon at ang sinusuportahang mekanismo nito sa pagbabahagi ng kredensyal sa halip na kopyahin ang landas ng executable mula sa lumang kliyente. Unang tiyakin kung aling pagkakakilanlan ang iaalok ng sistema:

security find-identity -v -p ssl-client

Pagbasa ng errSecInteractionNotAllowed

Ang status na iyon ay nag-uulat ng hindi pinahintulutang interaksyon sa Security Server, at walang sinasabi tungkol sa mga kadena ng sertipiko. Basahin ito kasama ang operasyon na lumikha nito: ang kahilingan sa pagpirma na inilabas mula sa kontekstong hindi makapagpapakita ng prompt ay mabibigo sa ganitong paraan kahit na ang susi at ang sertipiko ay ganap na balido. Ang simula ay ang operasyon na nagtala nito, hindi ang imbakan ng sertipiko. Anuman ang baguhin mo sa mga angkla ng pagtitiwala ay iiwan ang error kung saan mismo ito naroon.

Kaya ituring ang code bilang dahilan upang suriin ang konteksto ng pagpapatupad at awtorisasyon. Ang ituring itong patunay na hindi pinagkakatiwalaan ang CA ng gateway ay nagpapadala sa iyo sa maling kalahati ng suliranin, at ang pagbabagong gagawin mo roon ay hindi makakaapekto sa error.

Ayusin nang makitid, hindi malawak

Magsimula sa mga tagubilin sa pagpapatala o pag-import ng may-ari ng koneksyon. Itala ang bersyon ng kliyente, saklaw ng profile, napiling pagkakakilanlan at unang kaugnay na lokal na error, dahil ang apat na katotohanang iyon ang kailangan ng paghahatid sa suporta at doon nakasalalay ang susunod na paghahambing. Ang pinamamahalaang profile o pagkakakilanlang may suporta ng hardware ay maaaring mangailangan ng administrador o tagapagbigay ng serbisyo upang ayusin ang paghahatid, at walang dami ng lokal na pag-click ang makapapalit doon.

Kung saan inaasahan ng produkto ang pag-apruba ng gumagamit, tiyakin kung aling bahagi ang humihiling at aprubahan lamang ang access na iyon sa sinusuportahang daloy. Kung saan walang paraan ang bahagi upang magtaas ng prompt sa kontekstong pinapatakbo nito, ang paghahanda ay dapat sumunod sa rutang dokumentado ng vendor, hindi ng isang diyalogong hinila mula sa ibang bintana ng terminal.

Dalawang pagbabago ang pinagsama sa lumang payo, at parehong masyadong malawak. Ang pagbibigay sa bawat aplikasyon ng access sa pribadong susi ay nagpapalawak ng lokal na paggamit ng susi nang lampas sa pangangailangan, at ang pagtatakda ng sertipiko sa Always Trust ay nagbabago ng pagsusuri ng sertipiko para sa lahat ng nasa makina. Wala sa dalawa ang nagpapahayag ng “aprubadong implementasyong ito ng VPN, gamit ang nilalayong pagkakakilanlang ito”.

Suriin lokal bago basahin ang gateway

Pagkatapos ng pag-aayos, tiyakin na nagtatagumpay ang lokal na operasyon bago mo bigyang-kahulugan ang anumang tugon mula sa kabilang panig. Kung gumagana na ngayon ang pagpirma, ang susunod na pagtanggi sa pangalan, kadena o pagtanggap ng kliyente ay bagong resulta at hindi pag-ulit, at ito ay kabilang sa ibang desisyon na may ibang may-ari.

Ang kapaki-pakinabang na paghahatid ay pinapangalanan kung alin sa tatlong desisyon ang nabigo at humihinto doon. Hindi kailanman isinasama nito ang pribadong susi, at hindi kailanman nirereset ang mga walang kaugnayang item ng keychain sa pag-asang makakatulong ang malinis na kalagayan. Itakda ang dalawang gawi bago ang insidente at hindi habang nangyayari ito, kapag pinakamalakas ang tukso na subukan ang lahat nang sabay-sabay. Ang tiket na nagsasabing “muling itinayo ang keychain” ay halos walang sinasabi sa susunod na mambabasa tungkol sa orihinal na depekto.