Paano mag-import ng sertipiko ng VPN sa Android at i-verify ang key

Ang pag-import ng sertipiko ng kliyenteng VPN sa Android ay tumatagal ng ilang minuto. Ang pagtiyak na nakarating ito sa tamang lugar ay tumatagal ng mas matagal, at iyon ang bahaging nilalaktawan ng karamihan kapag sinabi ng dialog ng pag-install na matagumpay. Ang mensahe ng tagumpay ay nangangahulugan lamang na na-parse ang file. Wala itong sinasabi tungkol sa kung aling provider ang may hawak ng pribadong key o kung may natitira pang kopya sa iyong folder na Downloads.

Hakbang 1: Basahin ang P12 bago ito umalis sa iyong makina

Magsimula sa file mismo. Kung hindi mo mapangalanan ang paksa, ang nagbigay at ang petsa ng pag-expire sa loob nito, nag-import ka ng isang bagay na hindi mo maipapatunay mamaya.

Ang PKCS#12 na bundle ay karaniwang may dalang sertipiko ng kliyente, ang pribadong key nito at ang chain ng nagbigay. Ang openssl pkcs12 -in client.p12 -info -noout ay nagpi-print ng MAC at mga algorithm ng encryption nang hindi ibinubuhos ang key material, kaya makikita mo kung ang bundle ay protektado ng password at sa anong cipher. Sundan ito ng keytool -list -v -keystore client.p12 -storetype PKCS12 upang makuha ang alias, ang SHA-256 fingerprint at ang validity window na ihahambing mo sa telepono.

Ipadala ang password sa ibang channel kaysa sa file, o ibigay ang file sa loob ng pinamamahalaang daloy ng distribusyon na hindi nag-iiwan ng kopya. Ang password na idinikit sa parehong chat message ng archive ay ginagawang isa ang dalawang kontrol.

Hakbang 2: I-install ito sa slot na aktwal na binabasa ng app ng VPN

Sa stock na Android 11 hanggang 14 ang landas ay dumadaan sa Mga Setting, Seguridad, Encryption at mga kredensyal, Mag-install ng sertipiko, pagkatapos ay VPN at sertipiko ng user ng app. Nagbabago ang pananalita at nesting sa pagitan ng mga release at skin ng gumawa, kaya sundin ang label ng uri ng kredensyal sa halip na isang kabisadong posisyon sa menu. Sa work profile, mag-install mula sa loob ng panig ng trabaho, dahil hindi tumatawid ang mga kredensyal sa hangganan ng profile.

Huwag maglagay ng pagkakakilanlan ng kliyente sa slot ng sertipiko ng CA. Ang slot na iyon ay nagpapakain sa tindahan ng tiwala ng user, at mula noong Android 7 ay binabalewala ng mga app ang mga CA na idinagdag ng user maliban kung pinapayagan ng kanilang config ng seguridad sa network, kaya ang sertipiko ng kliyenteng inilagay doon ay hindi kailanman lumalabas sa pumipili ng key ng VPN.

Ang ilang kliyente ng VPN ay hindi kailanman humihipo sa tindahan ng system at sa halip ay nag-import ng P12 sa sarili nilang direktoryo ng app. Lehitimo iyon na disenyo, ngunit binabago nito ang bawat susunod na hakbang: ang key ay naninirahan na ngayon sa ilalim ng sandbox ng app at kasing lakas lamang ng paghawak ng app na iyon sa sarili nitong imbakan. Suriin ang dokumentasyon ng kliyente bago ipagpalagay na kasangkot ang KeyChain.

Hakbang 3: Patunayan kung aling provider ang may hawak ng key

Ang pag-import ay nagpapatunay ng pag-parse, hindi ng suporta sa hardware. Sa Android 12 at mas bago, ang KeyInfo.getSecurityLevel() ay nag-uulat kung ang isang key ay nasa Trusted Execution Environment, sa StrongBox o sa software, at pinapalitan nito ang mas lumang tawag na isInsideSecureHardware(). Kung hindi ipinapakita ng kliyente ng VPN ang halagang iyon, ang fingerprint mula sa hakbang 1 ang iyong reserba. Ang sertipikong muling na-encode sa panahon ng pag-import ay hindi magtutugma byte para sa byte, ngunit ang pampublikong key at ang paksa ay magtutugma pa rin.

Ang hindi ma-export ay hindi katulad ng hindi magagamit. Ang key na hindi makakaalis sa device ay magagamit pa rin ng anumang app na pinapayagan ng user na piliin ang alias na iyon, at iyon ang dahilan kung bakit ang prompt ng alias ay tunay na kontrol at hindi pormalidad. Ang dokumentasyon ng Android Keystore ay sulit basahin minsan kung ginagawa mo ang desisyong iyon sa disenyo.

Pagkatapos ay isaalang-alang ang mga kopyang ginawa mo. Ang P12 sa iyong laptop, ang nasa attachment ng ticket at ang nasa backup ng nakaraang buwan ay lahat pa ring valid na pagkakakilanlan hanggang sa bawiin sila ng nagbigay. Ang proteksyon ng hardware ng instance sa telepono ay walang ginagawa para sa mga iyon.

Hakbang 4: Alamin kung kanino pagmamay-ari ang pangangailangan ng lock ng screen

Tatlong sikreto ang naghahalo dito: ang PIN ng pag-unlock ng device, ang passphrase ng pribadong key at ang password ng account ng VPN. Ang prompt para sa isa ay hindi kailanman kahilingan na i-reset ang iba, at ang pag-reset ng mali ang paraan kung paano nagla-lock ang mga tao sa labas ng profile na maayos na gumagana.

Kapag ang isang administrator ng device o patakaran ng pinamamahalaang profile ay nangangailangan ng lock, ang pangangailangan ay pagmamay-ari ng patakarang iyon, hindi ng sertipiko. Ang adb shell dumpsys device_policy ay naglilista ng mga aktibong administrator at ang kalidad ng password na ipinapatupad nila, na siyang pinakamabilis na paraan upang makita kung ang isang ahente ng MDM ang dahilan ng pagbabago ng iyong mga patakaran sa PIN. Ang pag-alis ng sertipiko ay hindi magpapaluwag sa patakaran, at ang pag-alis ng patakaran ay desisyong administratibo at hindi pagsasaayos ng setting.

Asahan din ang isang trade-off sa kakayahang magamit. Kung ang key ay nangangailangan ng awtorisasyon ng user, hindi makakaangat ang tunnel bago ang unang pag-unlock, kaya ang mga naka-iskedyul na sync at remote wake-up ay nabibigo ayon sa disenyo. Magpasya tungkol doon bago ang deployment, hindi pagkatapos.

Iwasan ang shortcut ng pag-edit ng locksettings.db o muling pagpapatupad ng lumang solusyon para sa nakalimutang pattern. Ang mga rutinang iyon ay isinulat para sa partikular na mga build, maaari nilang iwanan ang tindahan ng kredensyal sa isang kalagayang hindi na inaasahan ng framework, at hindi nila kailanman binabago ang patakarang humingi ng lock sa simula.

Hakbang 5: Iretiro ang pagkakakilanlan at i-verify ang pagtanggi

Ang pagreretiro ay may tatlong bahagi at ang una lamang ang lokal. Alisin ang profile ng VPN, tanggalin ang sertipiko ng user sa ilalim ng Mga Setting, Seguridad, Encryption at mga kredensyal, Mga kredensyal ng user, pagkatapos ay ipaubaya sa nagbigay na bawiin ang serial number ng sertipiko. Ang lokal na pagtanggal lamang ay nag-iiwan ng kredensyal na tinatanggap pa rin ng server kung may nagtago ng P12.

I-verify ang resulta sa halip na ipagpalagay ito. Subukan ang koneksyon gamit ang retiradong profile at kumpirmahin na tinatanggihan ito ng server. Ang tunnel na umaangat pa rin ay nangangahulugan na binawi mo ang maling serial number o tahimik na bumagsak ang kliyente sa ibang naka-install na pagkakakilanlan.

Kung binabalik mo ang isang nabigong pag-import, muling i-import mula sa orihinal na naka-encrypt na bundle at muling suriin ang fingerprint sa halip na gamitin muli ang na-decrypt na key file na iniwan mo sa disk.