Помилка Keystore на Android VPN: перереєструвати, розблокувати чи повторити?
Три результати Android keystore вимагають трьох різних відновлень. Порівняйте розблокування, повторну реєстрацію та повтор у постачальника, перш ніж очищати сховище застосунку.
Профіль усе ще в списку, сертифікат усе ще відображається як установлений, а кнопка підключення завершується помилкою з повідомленням «Помилка Keystore» і більше нічого. Перш ніж очищати сховище застосунку чи здавати телефон, встановіть, яка операція з ключем не вдалася. Три результати породжують один і той самий діалог і відповідають на три різні дії — і лише одна з них руйнівна. Порівняння варте десяти хвилин, бо неправильна гілка коштує вам посвідчення, яке ви намагалися зберегти.
Три збої за одним діалогом
Перший — автентифікація. Ключ існує і є чинним, але його використання вимагає від користувача підтвердити присутність — розблокування пристрою, біометрію або запит робочого профілю. Якщо час блокування, зареєстрована біометрія або стан профілю нещодавно змінилися, використання ключа може не вдатися, хоча сам ключ цілком справний.
Другий — незворотна недійсність. Частину ключового матеріалу анулює політика платформи, коли скидають спосіб блокування або змінюють біометричну реєстрацію, бо прив'язка, що його захищала, більше не діє. Ключ неможливо відремонтувати, і повторна спроба не є планом відновлення; посвідчення треба замінити через процес реєстрації, який його видав.
Третій — збій постачальника: служба keystore не змогла виконати операцію прямо зараз. Це той клас, який іноді варто повторити, і єдиний.
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
Зверніть увагу: два з трьох не руйнівні, а один узагалі не має рішення на рівні пристрою. Жоден із них не вирішується стиранням телефона — кроком, який люди роблять першим, бо діалог не дає їм нічого іншого.
Повторна реєстрація проти очищення даних
Зовні вони виглядають схоже, але це не одне й те саме. Повторна реєстрація просить у системи-видавця нове посвідчення — свіжий сертифікат або ключ, прив'язаний до цього пристрою, — і виводить з обігу старе. Очищення даних видаляє збережений стан застосунку, що може прибрати посилання на ключ, не видаляючи сам ключ, або видалити ключ і залишити вас без повноважень відтворити його.
Різниця важлива, бо неекспортовані ключі за задумом непереносні. Вони живуть у сховищі ключів пристрою, підтримуваному доступним обладнанням або постачальником, і це не те, що захоплює резервна копія та відновлює відновлення. Якщо посвідчення в розгортанні — неекспортований ключ, плануйте повторну реєстрацію як відновлення і заздалегідь підтвердьте, що маєте схвалений шлях для її отримання — деякі організації вимагають для цього доступу до приватної мережі, який саме й забезпечував зламаний VPN.
Отже порядок: спробуйте підтримуваний шлях автентифікації, потім визначте, чи ключ незворотно недійсний, і замінюйте посвідчення лише якщо це так. Очищення сховища йде останнім, після того як ви знаєте, що буде відтворено, а не першим, бо це просто.
Повторюйте лише те, що можна повторити
Старіші версії платформи зводили помилки keystore до одного винятку, тому стільки клієнтів повторюють усе. Починаючи з API 33, тип винятку несе структуру: числову помилку, прапорець тимчасового збою та політику повторних спроб. Для розробника клієнта політика повторних спроб має сенс лише тоді, коли прапорець тимчасовості істинний; незворотна недійсність не має розкладу повторів, і довбати її в циклі лише садить батарею та забиває журнал.
Якщо ви діагностуєте, а не пишете клієнт, практичний наслідок той самий. Однакові збої за кожної спроби виключають разовий збій, але не відокремлюють незворотно анульований ключ від постачальника, що недоступний уже якийсь час — збій постачальника виглядає точно так само на десятому повторі, як і на першому. Без структурованих полів API 33 сприймайте повторюваність як привід шукати другий сигнал — код помилки, якщо ваша збірка його показує, стан оператора або успіх іншого ключа на тому самому пристрої — а не як доказ того, що ключ мертвий.
Читайте ланцюг причин, а не ярлик
Застосунки обгортають початковий виняток, і дружній рядок в інтерфейсі часто ховає єдине поле, яке визначає гілку. Збережіть ланцюг причин і позначку часу спроби: зовнішній виняток зазвичай називає операцію, а причина називає стан ключа.
Не піддавайтеся висновку, що два збійні застосунки доводять несправність телефона. Різні ключі можуть опиратися на різних постачальників і різні рівні безпеки, а застосунок, що ще працює, може взагалі не виконувати ту саму операцію — підпис, розшифрування й атестація ключа є різними запитами до однієї служби. Довідник KeyStoreException описує структуровані поля на новіших рівнях API і є місцем, де перевіряють, що ваша збірка справді може повідомити.
Те, що підтвердило б висновок про обладнання, вужче, ніж вважає більшість: та сама операція, у того самого постачальника, що збоїть на незалежних ключах із помилкою рівня постачальника, а не рівня ключа. Це питання до діагностики платформи, а не до гілки форуму підтримки про партію пристроїв.
Що записати, поки ви вирішуєте
Запишіть збірку Android, версію клієнта, вибраний профіль, операцію, що не вдалася, і чи щось нещодавно змінилося — оновлення ОС, зміна екрана блокування, новий відбиток пальця, повторна реєстрація. Записуйте послідовність як контекст, а не як доказ причини; зміна блокування перед збоєм ключа — правдоподібна кореляція, а не демонстрація.
Далі дійте за встановленою гілкою. Тимчасовий: збережіть посвідчення, використайте підтримуваний шлях повтору. Потрібна автентифікація: завершіть підтримуваний сценарій розблокування і збережіть політику блокування, яку вимагає розгортання, замість вимикати її, щоб обійти діалог. Незворотно недійсний: замініть і виведіть з обігу посвідчення через звичайну реєстрацію.
Завершіть, довівши результат на новому авторизованому підключенні до реального ресурсу з увімкненою перевіркою сервера. Усе, що працює лише з послабленими перевірками сертифікатів, не вирішило проблему ключа — воно перенесло її на мережевий рівень, де вона проявиться пізніше з гіршими симптомами.
- Три гілки: потрібна автентифікація, незворотно недійсний, тимчасовий збій постачальника.
- Лише третя виграє від повтору, і лише за її політикою повторів.
- Заміна через повторну реєстрацію відновлює доступ; очищення даних прибирає цю можливість.
- Перевірте на новому підключенні та за звичайних перевірок ідентичності сервера.