Ошибка Keystore на Android VPN: перерегистрировать, разблокировать или повторить?

Профиль всё ещё в списке, сертификат по-прежнему отображается как установленный, а кнопка подключения завершается ошибкой с сообщением «Ошибка Keystore» и больше ничем. Прежде чем очищать хранилище приложения или сдавать телефон в ремонт, установите, какая операция с ключом не удалась. Три исхода порождают один и тот же диалог и требуют трёх разных действий — и только одно из них разрушительное. Сравнение стоит десяти минут, потому что неверная ветка отнимает у вас удостоверение, которое вы пытались сохранить.

Три сбоя за одним диалогом

Первый — аутентификация. Ключ существует и действителен, но для его использования пользователь должен подтвердить присутствие — разблокировать устройство, пройти биометрию или ответить на запрос рабочего профиля. Если время блокировки, зарегистрированная биометрия или состояние профиля недавно изменились, использование ключа может не удаться, хотя сам ключ совершенно исправен.

Второй — необратимая недействительность. Часть ключевого материала аннулируется политикой платформы при сбросе способа блокировки или изменении биометрической регистрации, потому что привязка, которая его защищала, больше не действует. Ключ нельзя починить, и повторная попытка не является планом восстановления; удостоверение нужно заменить через процесс регистрации, который его выдал.

Третий — сбой поставщика: служба keystore не смогла выполнить операцию прямо сейчас. Это тот класс, который иногда стоит повторять, и единственный.

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

Повторная регистрация против очистки данных

Снаружи они выглядят похоже, но это не одно и то же. Повторная регистрация запрашивает у выдающей системы новое удостоверение — свежий сертификат или ключ, привязанный к этому устройству, — и выводит из обращения старое. Очистка данных удаляет сохранённое состояние приложения, что может убрать ссылку на ключ, не удаляя сам ключ, или удалить ключ и оставить вас без полномочий воссоздать его.

Различие важно, потому что неэкспортируемые ключи по замыслу непереносимы. Они живут в хранилище ключей устройства, опирающемся на доступное оборудование или поставщика, и это не то, что захватывает резервная копия и восстанавливает восстановление. Если удостоверение в развёртывании — неэкспортируемый ключ, планируйте повторную регистрацию как восстановление и заранее подтвердите, что у вас есть одобренный путь для её получения — некоторые организации требуют для этого доступ к частной сети, который как раз и обеспечивал сломанный VPN.

Итак, порядок: попробуйте поддерживаемый путь аутентификации, затем определите, действительно ли ключ необратимо недействителен, и заменяйте удостоверение только если это так. Очистка хранилища идёт последней, после того как вы знаете, что будет воссоздано, а не первой, потому что это просто.

Повторяйте только то, что можно повторить

Старые версии платформы сводили ошибки keystore к одному исключению, поэтому столько клиентов повторяют всё подряд. Начиная с API 33 тип исключения несёт структуру: числовой код ошибки, флаг временного сбоя и политику повторных попыток. Для разработчика клиента политика повторных попыток имеет смысл только когда флаг временного сбоя истинен; у необратимой недействительности нет расписания повторов, и долбить её в цикле просто сажает батарею и забивает журнал.

Если вы диагностируете, а не пишете клиент, практическое следствие то же. Одинаковые сбои при каждой попытке исключают разовый сбой, но не отделяют необратимо аннулированный ключ от поставщика, который недоступен уже какое-то время — сбой поставщика выглядит точно так же на десятом повторе, как и на первом. Без структурированных полей API 33 воспринимайте повторяемость как повод искать второй сигнал — код ошибки, если ваша сборка его показывает, состояние оператора или успех другого ключа на том же устройстве — а не как доказательство того, что ключ мёртв.

Читайте цепочку причин, а не ярлык

Приложения оборачивают исходное исключение, и дружелюбная строка в интерфейсе часто скрывает единственное поле, которое определяет ветку. Сохраните цепочку причин и метку времени попытки: внешнее исключение обычно называет операцию, а причина называет состояние ключа.

Не поддавайтесь выводу, что два сбойных приложения доказывают неисправность телефона. Разные ключи могут опираться на разных поставщиков и разные уровни безопасности, а работающее приложение может вообще не выполнять ту же операцию — подпись, расшифровка и аттестация ключа являются разными запросами к одной и той же службе. Справочник KeyStoreException описывает структурированные поля на новых уровнях API и является местом, где проверяют, что ваша сборка действительно может сообщить.

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

Что записать, пока вы решаете

Запишите сборку Android, версию клиента, выбранный профиль, операцию, которая не удалась, и менялось ли что-то недавно — обновление ОС, изменение экрана блокировки, новый отпечаток, повторная регистрация. Записывайте последовательность как контекст, а не как доказательство причины; изменение блокировки перед сбоем ключа — правдоподобная корреляция, а не демонстрация.

Затем действуйте по установленной ветке. Временный сбой: сохраните удостоверение, используйте поддерживаемый путь повтора. Требуется аутентификация: пройдите поддерживаемый сценарий разблокировки и сохраните политику блокировки, которую требует развёртывание, вместо того чтобы отключать её ради обхода диалога. Необратимо недействителен: замените и выведите из обращения удостоверение через обычную регистрацию.

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

• Три ветки: нужна аутентификация, необратимо недействителен, временный сбой поставщика.
• Только третья выигрывает от повтора, и только по её политике повторов.
• Замена через повторную регистрацию восстанавливает доступ; очистка данных убирает эту возможность.
• Проверьте на новом подключении и при обычной проверке идентичности сервера.