Kiel importi VPN-atestilon en Android kaj kontroli la ŝlosilon

Importi VPN-klientan atestilon en Android daŭras kelkajn minutojn. Kontroli, ĉu ĝi alvenis al la ĝusta loko, daŭras pli longe, kaj ĝuste tiun parton plej multaj homoj preterlasas, kiam la instala dialogo diras sukceso. Sukcesa mesaĝo nur signifas, ke la dosiero estis analizita. Ĝi diras nenion pri tio, kiu provizanto tenas la privatan ŝlosilon aŭ ĉu kopio ankoraŭ sidas en via dosierujo Downloads.

Paŝo 1: Legu la P12 antaŭ ol ĝi forlasos vian maŝinon

Komencu per la dosiero mem. Se vi ne povas nomi la subjekton, la eldoninton kaj la findaton ene de ĝi, vi importas ion, kion vi ne povos kontroli poste.

PKCS#12-pakaĵo kutime portas klientan atestilon, ĝian privatan ŝlosilon kaj la eldonintan ĉenon. openssl pkcs12 -in client.p12 -info -noout presas la MAC kaj la ĉifrajn algoritmojn sen elporti ŝlosilan materialon, do vi vidas, ĉu la pakaĵo estas pasvortprotektita kaj per kiu ĉifro. Sekvu per keytool -list -v -keystore client.p12 -storetype PKCS12 por akiri la alinomon, la SHA-256-fingrospuron kaj la validecan fenestron, kiun vi komparos kun la telefono.

Sendu la pasvorton per alia kanalo ol la dosiero, aŭ transdonu la dosieron ene de administrata dissenda fluo, kiu lasas neniun kopion. Pasvorto algluita en la sama babilmesaĝo kiel la arkivo transformas du kontrolojn en unu.

Paŝo 2: Instalu ĝin en la fendon, kiun la VPN-aplikaĵo efektive legas

Sur norma Android 11 ĝis 14 la vojo iras tra Agordoj, Sekureco, Ĉifrado kaj akreditaĵoj, Instali atestilon, poste VPN kaj aplikaĵa uzanta atestilo. La vortigo kaj la nestado moviĝas inter eldonoj kaj fabrikantaj haŭtoj, do sekvu la etikedon de la akreditaĵa tipo anstataŭ memortenigitan menuopozicion. En labora profilo, instaligu de interne de la labora flanko, ĉar akreditaĵoj ne transiras la profilan limon.

Ne metu klientan identecon en la CA-atestilan fendon. Tiu fendo nutras la uzantan fido-tenejon, kaj ekde Android 7 aplikaĵoj ignoras uzant-aldonitajn CA-ojn krom se ilia retsekureca agordo tion permesas, do klienta atestilo lasita tie neniam aperas en la VPN-ŝlosila elektilo.

Iuj VPN-klientoj neniam tuŝas la sisteman tenejon kaj anstataŭe importas la P12 en sian propran aplikaĵan dosierujon. Tio estas legitima dezajno, sed ĝi ŝanĝas ĉiun postan paŝon: la ŝlosilo nun vivas sub la aplikaĵa sablujo kaj estas ekzakte tiel forta, kiel tiu aplikaĵo traktas sian propran stokadon. Kontrolu la klientan dokumentaron antaŭ ol supozi, ke KeyChain rolas.

Paŝo 3: Pruvu, kiu provizanto tenas la ŝlosilon

Importo konfirmas analizon, ne aparatan subtenon. Sur Android 12 kaj poste, KeyInfo.getSecurityLevel() raportas, ĉu ŝlosilo sidas en la Fidinda Ekzekuta Medio, en StrongBox aŭ en programaro, kaj ĝi anstataŭas la pli malnovan alvokon isInsideSecureHardware(). Se la VPN-kliento ne montras tiun valoron, la fingrospuro el paŝo 1 estas via rezervo. Atestilo rekodigita dum importo ne kongruos bajte post bajto, sed la publika ŝlosilo kaj la subjekto ankoraŭ kongruos.

Ne-eksportebla ne samas kiel neuzebla. Ŝlosilon, kiu ne povas forlasi la aparaton, ankoraŭ povas uzi iu ajn aplikaĵo, kiun la uzanto rajtigas elekti tiun alinomon, kaj tial la alinoma peto estas reala kontrolo, ne formalaĵo. La dokumentaro de Android Keystore indas unufojan legadon, se vi faras tiun dezajnan decidon.

Poste kalkulu la kopiojn, kiujn vi faris. La P12 sur via tekokomputilo, tiu en la bileta aldonaĵo kaj tiu en la pasintmonata sekurkopio ĉiuj restas validaj identecoj ĝis la eldoninto revokos ilin. Aparata protekto de la instanco en la telefono faras nenion por tiuj.

Paŝo 4: Trovu, kiu posedas la ekranŝlosan postulon

Tri sekretoj konfuziĝas ĉi tie: la malŝlosa PIN de la aparato, la pasfrazo de la privata ŝlosilo kaj la pasvorto de la VPN-konto. Peto por unu neniam estas peto restarigi la aliajn, kaj restarigi la malĝustan estas kiel homoj sin ŝlosas el profilo, kiu funkciis bone.

Kiam aparata administranto aŭ administrata profila politiko postulas ŝloson, la postulo apartenas al tiu politiko, ne al la atestilo. adb shell dumpsys device_policy listigas la aktivajn administrantojn kaj la pasvortkvaliton, kiun ili devigas, kio estas la plej rapida maniero vidi, ĉu MDM-agento estas la kialo, ke viaj PIN-reguloj ŝanĝiĝis. Forigi la atestilon ne malstreĉos la politikon, kaj forigi la politikon estas administra decido, ne agorda ĝustigo.

Atendu ankaŭ uzeblecan kompromison. Se la ŝlosilo postulas uzantan rajtigon, la tunelo ne povas leviĝi antaŭ la unua malŝloso, do planitaj sinkronigoj kaj telerevokoj malsukcesas laŭdezajne. Decidu tion antaŭ la enkonduko, ne poste.

Evitu la fuŝvojon redakti locksettings.db aŭ reludi malnovan ĉirkaŭvojon por forgesita ŝablono. Tiuj rutinoj estis skribitaj por specifaj konstruaĵoj, ili povas lasi la akreditaĵan tenejon en stato, kiun la kadro ne plu atendas, kaj ili neniam ŝanĝas la politikon, kiu petis la ŝloson unue.

Paŝo 5: Retiru la identecon kaj kontrolu la rifuzon

Retiro havas tri partojn kaj nur la unua estas loka. Forigu la VPN-profilon, viŝu la uzantan atestilon sub Agordoj, Sekureco, Ĉifrado kaj akreditaĵoj, Uzantaj akreditaĵoj, poste lasu la eldoninton revoki la serian numeron de la atestilo. La loka viŝo sola lasas akreditaĵon, kiun la servilo ankoraŭ akceptas, se iu konservis la P12.

Kontrolu la rezulton anstataŭ supozi ĝin. Provu konekton kun la retirita profilo kaj konfirmu, ke la servilo rifuzas ĝin. Tunelo, kiu ankoraŭ leviĝas, signifas, ke vi revokis la malĝustan serian numeron aŭ ke la kliento silente falis al alia instalita identeco.

Se vi malfaras malsukcesan importon, reimportu el la originala ĉifrita pakaĵo kaj rekontrolu la fingrospuron anstataŭ reuzi malĉifritan ŝlosilan dosieron, kiun vi lasis sur la disko.