Како увести VPN сертификат на Андроиду и проверити кључ

Увоз VPN клијентског сертификата на Андроиду траје неколико минута. Провера да је слетео на право место траје дуже, а то је део који већина људи прескочи када дијалог за инсталацију каже да је успешно. Порука о успеху значи само да је датотека парсирана. Не говори ништа о томе који добављач држи приватни кључ ни да ли копија још стоји у вашој фасцикли 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 апликација заиста чита

На стандардном Андроиду 11 до 14 пут иде кроз Подешавања, Безбедност, Шифровање и акредитиви, Инсталирај сертификат, затим VPN и кориснички сертификат апликације. Формулација и угнежђивање се мењају између издања и произвођачких љуски, зато пратите ознаку типа акредитива, а не запамћену позицију менија. У радном профилу инсталирајте из унутрашњости радне стране, јер акредитиви не прелазе границу профила.

Не стављајте клијентски идентитет у отвор за CA сертификат. Тај отвор храни складиште поверења корисника, а од Андроида 7 апликације игноришу CA које је додао корисник осим ако то њихова конфигурација мрежне безбедности не дозвољава, па се клијентски сертификат остављен тамо никада не појављује у бирачу кључева VPN-а.

Неки VPN клијенти никада не дирају системско складиште и уместо тога увозе P12 у сопствени директоријум апликације. То је легитиман дизајн, али мења сваки каснији корак: кључ сада живи у пешчанику апликације и јак је тачно онолико колико та апликација управља сопственим складиштем. Проверите документацију клијента пре него што претпоставите да је KeyChain у игри.

Корак 3: Докажите који добављач држи кључ

Увоз потврђује парсирање, не хардверску подршку. На Андроиду 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.

Проверите резултат уместо да га претпоставите. Покушајте везу са повученим профилом и потврдите да је сервер одбија. Тунел који се још диже значи да сте опозвали погрешан серијски број или да је клијент тихо прешао на други инсталирани идентитет.

Ако враћате неуспешан увоз, поново увезите из оригиналног шифрованог пакета и поново проверите отисак уместо да поново користите дешифровану датотеку кључа коју сте оставили на диску.