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

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

Если вы откатываете неудачный импорт, импортируйте заново из исходного зашифрованного пакета и перепроверьте отпечаток, а не используйте повторно расшифрованный файл ключа, оставленный на диске.