Як імпортувати сертифікат 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.

Перевірте результат, а не припускайте його. Спробуйте з'єднання з відкликаним профілем і переконайтеся, що сервер його відхиляє. Тунель, який усе ще піднімається, означає, що ви відкликали не той серійний номер або клієнт тихо перейшов на іншу встановлену ідентичність.

Якщо ви відкочуєте невдалий імпорт, імпортуйте заново з оригінального зашифрованого пакета і перевірте відбиток ще раз, а не використовуйте повторно розшифрований файл ключа, залишений на диску.