Як імпартаваць сертыфікат VPN на Android і праверыць ключ

Імпарт кліенцкага сертыфіката VPN на Android займае пару хвілін. Праверка таго, што ён трапіў у патрэбнае месца, займае больш часу, і менавіта гэтую частку большасць людзей прапускае, калі дыялог усталявання паведамляе пра поспех. Паведамленне пра поспех азначае толькі тое, што файл быў разабраны. Яно нічога не кажа пра тое, які пастаўшчык трымае прыватны ключ, ці не ляжыць яшчэ копія ў вашай папцы Downloads.

Крок 1: Прачытайце P12, перш чым ён пакіне вашу машыну

Пачніце з самога файла. Калі вы не можаце назваць суб'ект, выдаўца і тэрмін дзеяння ўнутры яго, вы імпартуеце нешта, што не зможаце праверыць пазней.

Пакет PKCS#12 звычайна змяшчае кліенцкі сертыфікат, яго прыватны ключ і ланцужок выдаўца. openssl pkcs12 -in client.p12 -info -noout друкуе MAC і алгарытмы шыфравання, не выводзячы матэрыял ключа, таму вы бачыце, ці абаронены пакет паролем і якім шыфрам. Далей выканайце keytool -list -v -keystore client.p12 -storetype PKCS12, каб атрымаць псеўданім, адбітак SHA-256 і акно сапраўднасці, якое вы параўнаеце з тэлефонам.

Перадавайце пароль іншым каналам, чым файл, або перадайце файл унутры кіраванага працэсу размеркавання, які не пакідае копіі. Пароль, устаўлены ў тое ж паведамленне чата, што і архіў, ператварае дзве меры ў адну.

Крок 2: Усталюйце яго ў той слот, які праграма VPN сапраўды чытае

На стандартным Android 11 да 14 шлях ідзе праз Налады, Бяспека, Шыфраванне і ўліковыя даныя, Усталяваць сертыфікат, затым VPN і сертыфікат карыстальніка праграмы. Фармулёўка і ўкладанне змяняюцца паміж выпускамі і абалонкамі вытворцаў, таму арыентуйцеся на этыкетку тыпу ўліковых даных, а не на запомнены пункт меню. У працоўным профілі ўсталёўвайце знутры працоўнага боку, бо ўліковыя даныя не перасякаюць мяжу профілю.

Не змяшчайце кліенцкую ідэнтычнасць у слот сертыфіката CA. Гэты слот сілкуе сховішча даверу карыстальніка, а пачынаючы з Android 7 праграмы ігнаруюць дададзеныя карыстальнікам CA, калі іх канфігурацыя сеткавай бяспекі не дазваляе гэта, таму кліенцкі сертыфікат, пакінуты там, ніколі не з'явіцца ў выбары ключоў VPN.

Некаторыя кліенты VPN наогул не звяртаюцца да сістэмнага сховішча і замест гэтага імпартуюць P12 у сваю ўласную тэчку праграмы. Гэта законны дызайн, але ён змяняе кожны наступны крок: ключ цяпер жыве ў пясочніцы праграмы і настолькі моцны, наколькі гэтая праграма кіруе ўласным сховішчам. Праверце дакументацыю кліента, перш чым меркаваць, што задзейнічаны KeyChain.

Крок 3: Дакажыце, які пастаўшчык трымае ключ

Імпарт пацвярджае разбор, а не апаратную абарону. На Android 12 і пазней KeyInfo.getSecurityLevel() паведамляе, ці знаходзіцца ключ у давераным асяроддзі выканання, у StrongBox ці ў праграмным забеспячэнні, і гэта замяняе старэйшы выклік isInsideSecureHardware(). Калі кліент VPN не паказвае гэта значэнне, адбітак з кроку 1 — ваша запасная магчымасць. Сертыфікат, перакадаваны падчас імпарту, не супадзе байт у байт, але публічны ключ і суб'ект усё роўна супадуць.

Неэкспартуемы не значыць непрыдатны. Ключ, які не можа пакінуць прыладу, усё яшчэ можа выкарыстоўвацца любой праграмай, якой карыстальнік дазволіць выбраць гэты псеўданім, і таму запыт псеўданіма — сапраўдная мера, а не фармальнасць. Дакументацыя Android Keystore вартая аднаго прачытання, калі вы прымаеце гэтае дызайнерскае рашэнне.

Затым улічыце зробленыя копіі. P12 на вашым ноўтбуку, той, што ў прыкладзеным да тыкета файле, і той, што ў леташнім рэзервовым капіі, — усе яны дзейныя ідэнтычнасці, пакуль выдавец іх не адкліча. Апаратная абарона асобніка на тэлефоне для іх не робіць нічога.

Крок 4: Высветліце, каму належыць патрабаванне блакіроўкі экрана

Тут блытаюць тры сакрэты: PIN разблакіроўкі прылады, парольная фраза прыватнага ключа і пароль уліковага запісу VPN. Запыт аднаго з іх ніколі не азначае просьбу скінуць іншыя, і скіданне не таго — менавіта так людзі блакуюць сябе ў профілі, які дагэтуль працаваў спакойна.

Калі адміністратар прылады або палітыка кіраванага профілю патрабуе блакіроўкі, патрабаванне належыць гэтай палітыцы, а не сертыфікату. adb shell dumpsys device_policy пералічвае актыўных адміністратараў і якасць пароля, якую яны ўводзяць, і гэта найхутчэйшы спосаб убачыць, ці агент MDM стаў прычынай змены вашых правіл PIN. Выдаленне сертыфіката не паслабіць палітыку, а выдаленне палітыкі — адміністрацыйнае рашэнне, а не папраўка налад.

Чакайце і кампраміс зручнасці. Калі ключ патрабуе дазволу карыстальніка, тунель не можа ўзняцца да першай разблакіроўкі, таму запланаваныя сінхранізацыі і аддаленыя абуджэнні правальваюцца па задуме. Вырашыце гэта да разгортвання, а не пасля.

Пазбягайце хуткага шляху — рэдагавання locksettings.db або паўтору старога абыходжання для забытага ўзору. Гэтыя руціны пісаліся для пэўных зборак, яны могуць пакінуць сховішча ўліковых даных у стане, якога фрэймворк ужо не чакае, і яны ніколі не змяняюць палітыку, якая запатрабавала блакіроўкі ў першую чаргу.

Крок 5: Зніміце ідэнтычнасць і праверце адмову

Зняцце мае тры часткі, і толькі першая лакальная. Выдаліце профіль VPN, выдаліце сертыфікат карыстальніка ў раздзеле Налады, Бяспека, Шыфраванне і ўліковыя даныя, Уліковыя даныя карыстальніка, затым дайце выдаўцу адклікаць серыйны нумар сертыфіката. Лакальнае выдаленне само па сабе пакідае ўліковыя даныя, якія сервер усё яшчэ прымае, калі нехта захаваў P12.

Праверце вынік, а не меркавайце. Паспрабуйце злучэнне са знятым профілем і пацвердзіце, што сервер яго адхіляе. Тунель, які ўсё яшчэ ўздымаецца, азначае, што вы адклікалі не той серыйны нумар або кліент маўкліва перайшоў на іншую ўсталяваную ідэнтычнасць.

Калі вы адкочваеце няўдалы імпарт, паўторна імпартуйце з арыгінальнага зашыфраванага пакета і пераправерце адбітак, а не выкарыстоўвайце паўторна расшыфраваны файл ключа, пакінуты на дыску.