Грешка в Keystore на Android VPN: ново записване, отключване или повторен опит?

Профилът все още е в списъка, сертификатът все още се показва като инсталиран, а бутонът за свързване се проваля със съобщение, което казва само „Грешка в Keystore“ и нищо друго. Преди да изчистите хранилището на приложението или да предадете телефона, установете коя операция с ключа се е провалила. Три изхода водят до същия диалог и те отговарят на три различни действия — само едно от които е разрушително. Сравнението си струва десет минути, защото грешният клон ви струва самоличността, която сте се опитвали да запазите.

Три провала зад един диалог

Първият е удостоверяването. Ключът съществува и е валиден, но използването му изисква потребителят да докаже присъствие — отключване на устройството, биометрия или предизвикателство от работния профил. Ако времето за заключване, записаната биометрия или състоянието на профила са се променили наскоро, използването на ключа може да се провали, докато самият ключ е напълно наред.

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

Третият е провал при доставчика: услугата за хранилище на ключове не успя да довърши операцията точно сега. Това е класът, който понякога си струва да се повтори, и единственият такъв.

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

Ново записване срещу изчистване на данни

Тези две изглеждат подобни отвън и не са. Новото записване иска от издаващата система нова самоличност — нов сертификат или ключ, обвързан с това устройство — и пенсионира стария. Изчистването на данни изтрива запазеното състояние на приложението, което може да премахне препратката към ключа, без да премахне ключа, или може да премахне ключа и да ви остави без право да го създадете отново.

Разликата е важна, защото неекспортируемите ключове по проект не са преносими. Те живеят в хранилището на устройството, подкрепени от какъвто хардуер или доставчик е наличен, и не са нещо, което резервно копие улавя и възстановяване връща. Ако самоличността на внедряването е неекспортируем ключ, планирайте ново записване като възстановяване и потвърдете предварително, че имате одобрен път да получите това записване — някои организации изискват достъп до частна мрежа за него, което е точно това, което осигуряваше счупеният VPN.

Значи редът е: опитайте поддържания път за удостоверяване, после определете дали ключът е окончателно невалиден, и заменете самоличността само ако е така. Изчистването на хранилището е последно, след като знаете какво ще бъде създадено наново, а не първо, защото е лесно.

Повтаряйте само това, което може да се повтори

По-старите версии на платформата събираха грешките на хранилището в едно изключение и затова толкова много клиенти повтарят всичко. От API 33 типът на изключението носи структура: числова грешка, флаг за временен провал и политика за повторение. За разработчика на клиент политиката за повторение има смисъл само когато флагът за временност е верен; окончателното обезсилване няма график за повторение и удрянето му в цикъл просто изтощава батерията и пълни журнала.

Ако диагностицирате, вместо да пишете клиента, практическата последица е същата. Еднаквите провали при всеки опит изключват еднократен глюк, но не отделят окончателно обезсилен ключ от доставчик, който е недостъпен от известно време — прекъсване при доставчика изглежда точно същото при десетия опит, както при първия. Без структурираните полета на API 33 третирайте повторението като причина да търсите втори сигнал — кодът на грешката, ако вашата сборка го показва, статусът на оператора или друг ключ на същото устройство, който успява — а не като доказателство, че ключът е мъртъв.

Четете веригата от причини, не етикета

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

Противете се на извода, че две неуспешни приложения доказват дефектен апарат. Различните ключове могат да бъдат подкрепени от различни доставчици и нива на сигурност, а приложение, което още работи, може изобщо да не изпълнява същата операция — подпис, дешифриране и атестация на ключ са различни заявки към една и съща услуга. справката KeyStoreException описва структурираните полета при по-нови API нива и е мястото, където да проверите какво вашата сборка всъщност може да докладва.

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

Какво да записвате, докато решавате

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

След това действайте по клона, който установихте. Временен: запазете самоличността, използвайте поддържания път за повторение. Изисква се удостоверяване: завършете поддържания поток за отключване и запазете политиката за заключване, която внедряването изисква, вместо да я изключвате, за да преминете диалог. Окончателно невалиден: заменете и пенсионирайте самоличността чрез нормално записване.

Завършете, като докажете резултата на нова разрешена връзка, към реален ресурс, с все още включена проверка на сървъра. Всичко, което работи само с отслабени проверки на сертификати, не е поправило проблема с ключа — преместило го е в мрежовия слой, където ще се появи по-късно с по-лоши симптоми.

• Три клона: изисква удостоверяване, окончателно невалиден, временен при доставчика.
• Само третият печели от повторение и само според своята политика за повторение.
• Заместващото записване връща достъпа; изчистването на данни премахва тази възможност.
• Проверете с нова връзка и нормални проверки за самоличност на сървъра.