Грешка со Keystore на Android VPN: повторна регистрација, отклучување или обид повторно?

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

Три неуспеси зад еден дијалог

Првиот е автентикација. Клучот постои и е валиден, но неговото користење бара корисникот да докаже присутност — отклучување на уредот, биометрија или предизвик од работниот профил. Ако временското ограничување на заклучувањето, регистрираната биометрија или состојбата на профилот неодамна се смениле, користењето на клучот може да не успее, додека самиот клуч е сосема во ред.

Вториот е трајно поништување. Некој материјал од клучеви платформата го поништува со политика кога ќе се ресетира методот на заклучување или ќе се смени биометриската регистрација, бидејќи врската што го штитела веќе не важи. Клучот не може да се поправи и повторниот обид не е план за враќање; идентитетот мора да се замени преку процесот на регистрација што го издал.

Третиот е неуспех кај провајдерот: keystore услугата не можеше да ја заврши операцијата сега. Ова е класата што понекогаш вреди да се повтори, и единствената.

Забележете дека два од трите не се разорни и едниот воопшто нема решение на ниво на уред. Ниту еден не се решава со бришење на телефонот, а токму тој чекор луѓето го прават прв, бидејќи дијалогот не им дава ништо друго.

Повторна регистрација наспроти бришење податоци

Овие две изгледаат слично однадвор и не се. Повторната регистрација бара од системот што издава нов идентитет — свеж сертификат или клуч поврзан со овој уред — и го пензионира стариот. Бришењето податоци ја брише зачуваната состојба на апликацијата, што може да ја отстрани референцата кон клучот без да го отстрани клучот, или може да го отстрани клучот и да ве остави без овластување да го создадете повторно.

Разликата е важна бидејќи клучевите што не можат да се извезат по дизајн не се преносливи. Тие живеат во keystore на уредот, поддржани од кој и да е достапен хардвер или провајдер, и не се нешто што резервна копија го фаќа, а враќањето го враќа. Ако идентитетот на распоредувањето е клуч што не може да се извезе, планирајте повторна регистрација како враќање и однапред потврдете дека имате одобрен пат за да ја добиете таа регистрација — некои организации за тоа бараат пристап до приватна мрежа, што е токму она што го обезбедуваше расипаниот VPN.

Значи редоследот е: пробајте го поддржаниот пат за автентикација, потоа утврдете дали клучот е трајно невалиден, и заменете го идентитетот само ако е. Бришењето на меморијата е последно, откако ќе знаете што ќе се создаде повторно, а не прво затоа што е лесно.

Повторете само она што може да се повтори

Поновите верзии на платформата ги групираа грешките на keystore во една исклучок, и затоа толку многу клиенти повторуваат сето. Од API 33 типот на исклучокот носи структура: нумеричка грешка, знаменце за привремен неуспех и политика за повторување. За развивач на клиент, политиката за повторување има смисла само кога знаменцето за привременост е точно; трајното поништување нема распоред за повторување, а удирањето по него во јамка само ја троши батеријата и го полни дневникот.

Ако дијагностицирате наместо да го пишувате клиентот, практичната последица е иста. Идентичните неуспеси при секој обид исклучуваат еднократен дефект, но не одвојуваат трајно поништен клуч од провајдер што е недостапен веќе некое време — прекинот кај провајдерот изгледа сосема исто на десеттиот обид како и на првиот. Без структурираните полиња на API 33, третирајте го повторувањето како причина да барате втор сигнал — кодот на грешката ако вашата градба го покажува, статусот на операторот или успехот на друг клуч на истиот уред — а не како доказ дека клучот е мртов.

Читајте го синџирот на причини, не етикетата

Апликациите го завиткуваат оригиналниот исклучок, а пријателскиот текст во интерфејсот често го крие единственото поле што ја одредува гранката. Зачувајте го синџирот на причини и временската ознака на обидот: надворешниот исклучок обично ја именува операцијата, а причината ја именува состојбата на клучот.

Спротивставете се на заклучокот дека две апликации што не успеваат докажуваат неисправен телефон. Различни клучеви можат да бидат поддржани од различни провајдери и нивоа на безбедност, а апликација што уште работи може воопшто да не ја извршува истата операција — потписот, дешифрирањето и атестацијата на клучот се различни барања до истата услуга. референца за KeyStoreException ги опишува структурираните полиња на поновите API нивоа и е местото каде што проверувате што вашата градба навистина може да пријави.

Она што би поддржало заклучок за хардвер е потесно отколку што повеќето претпоставуваат: истата операција, кај истиот провајдер, не успева кај независни клучеви со грешка на ниво на провајдер, а не на ниво на клуч. Тоа е прашање за дијагностиката на платформата, не за тема на форум за поддршка за серија уреди.

Што да запишете додека одлучувате

Запишете ја градбата на Android, верзијата на клиентот, избраниот профил, операцијата што не успеала и дали нешто неодамна се сменило — ажурирање на ОС, промена на екранот за заклучување, нов отпечаток, повторна регистрација. Запишете ја низата како контекст, а не како доказ за причина; промената на заклучувањето пред неуспех на клучот е веројатна корелација, не демонстрација.

Потоа постапете според гранката што ја утврдивте. Привремено: задржете го идентитетот, користете го поддржаниот пат за повторување. Потребна е автентикација: завршете го поддржаниот тек на отклучување и задржете ја политиката за заклучување што ја бара распоредувањето наместо да ја исклучите за да поминете дијалог. Трајно невалидно: заменете го и пензионирајте го идентитетот преку нормална регистрација.

Завршете со докажување на резултатот на нова овластена врска, до вистински ресурс, со валидацијата на серверот уште вклучена. Сето што работи само со олабавени проверки на сертификати не го реши проблемот со клучот — го премести во мрежниот слој, каде што подоцна ќе се појави со полоши симптоми.

• Три гранки: потребна е автентикација, трајно невалидно, привремено кај провајдерот.
• Само третата има полза од повторување, и тоа само според сопствената политика за повторување.
• Заменската регистрација го враќа пристапот; бришењето податоци ја отстранува таа можност.
• Проверете со нова врска и нормални проверки на идентитетот на серверот.