Памылка Keystore у Android VPN: перазапісацца, разблакаваць ці паўтарыць спробу?
Тры вынікі працы сховішча ключоў Android патрабуюць трох розных шляхоў аднаўлення. Параўнайце разблакаванне, перазапіс і паўторную спробу ў пастаўшчыка, перш чым ачышчаць сховішча праграмы.
Профіль па-ранейшаму ў спісе, сертыфікат па-ранейшаму паказваецца як усталяваны, а кнопка злучэння выдае памылку з паведамленнем «Памылка 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.
Такім чынам, парадак такі: паспрабуйце падтрыманы шлях аўтэнтыфікацыі, потым вызначце, ці ключ канчаткова ануляваны, і замяняйце ідэнтычнасць толькі калі так. Ачыстка сховішча ідзе апошняй, пасля таго як вы даведаецеся, што будзе створана нанова, а не першай, бо гэта лёгка.
Паўтарайце толькі тое, што можна паўтарыць
Старыя версіі платформы згортвалі памылкі сховішча ключоў у адзінае выключэнне, і таму столькі кліентаў паўтараюць усё. Пачынаючы з API 33, тып выключэння нясе структуру: лікавую памылку, сцяг часовага збою і палітыку паўтору. Для распрацоўшчыка кліента палітыка паўтору мае сэнс толькі тады, калі сцяг часовага збою праўдзівы; канчатковае ануляванне не мае графіка паўтору, і біць па ім у цыкле — гэта проста садзіць батарэю і запоўніць журнал.
Калі вы дыягнастуеце, а не пішаце кліент, практычны вынік той самы. Аднолькавыя збоі пры кожнай спробе выключаюць разовы глюк, але яны не аддзяляюць канчаткова ануляваны ключ ад пастаўшчыка, які недаступны ўжо некаторы час — збой пастаўшчыка выглядае аднолькава на дзясятай спробе і на першай. Без структураваных палёў API 33 разглядайце паўтор як прычыну шукаць другі сігнал — код памылкі, калі ваша зборка яго паказвае, статус аператара або іншы ключ на той самай прыладзе, які спрацуе, — а не як доказ таго, што ключ мёртвы.
Чытайце ланцуг прычын, а не ярлык
Праграмы абгортваюць зыходнае выключэнне, і прыязны радок у інтэрфейсе часта хавае адзінае поле, якое вызначае галіну. Захавайце ланцуг прычын і пазнаку часу спробы: знешняе выключэнне звычайна называе аперацыю, а прычына называе стан ключа.
Супраціўцеся выснове, што дзве праграмы са збоямі даказваюць дэфект прылады. Розныя ключы могуць падтрымлівацца рознымі пастаўшчыкамі і ўзроўнямі бяспекі, а праграма, якая яшчэ працуе, можа зусім не выконваць тую ж аперацыю — подпіс, дэшыфраванне і атэстацыя ключа ёсць розныя запыты да адной службы. даведка KeyStoreException апісвае структураваныя палі на больш новых узроўнях API і ёсць месцам, дзе праверыць, што ваша зборка сапраўды можа паведаміць.
Што падтрымала б выснову пра абсталяванне, вузка, чым большасць меркавала: тая ж аперацыя ў таго ж пастаўшчыка дае збой на незалежных ключах з памылкай узроўню пастаўшчыка, а не ключа. Гэта пытанне да дыягностыкі платформы, а не да тэмы на форуме падтрымкі пра партыю прылад.
Што запісваць, пакуль вы вырашаеце
Запішыце зборку Android, версію кліента, выбраны профіль, аперацыю, якая не ўдалася, і ці не змянілася нядаўна нешта — абнаўленне аперацыйнай сістэмы, змена экрана блакавання, новы адбітак пальца, перазапіс. Запісвайце паслядоўнасць як кантэкст, а не як доказ прычыны; змена блакавання перад збоем ключа — праўдападобная карэляцыя, а не дэманстрацыя.
Затым дзейнічайце па галіне, якую вызначылі. Часовы: захавайце ідэнтычнасць, выкарыстоўвайце падтрыманы шлях паўтору. Патрабуецца аўтэнтыфікацыя: прайдзіце падтрыманы працэс разблакавання і захоўвайце палітыку блакавання, якую патрабуе разгортванне, а не адключайце яе, каб абысці дыялог. Канчаткова ануляваны: заменіце і адпраўце ідэнтычнасць на спакой праз звычайную рэгістрацыю.
Завяршыце доказам выніку на свежым дазволеным злучэнні, да рэальнага рэсурсу, з па-ранейшаму ўключанай праверкай сервера. Усё, што працуе толькі з паслабленымі праверкамі сертыфікатаў, не выправіла праблему ключа — яно перанесла яе ў сеткавы ўзровень, дзе яна выявіцца пазней з горшымі сімптомамі.
- Тры галіны: патрабуецца аўтэнтыфікацыя, канчаткова ануляваны, часовы збой пастаўшчыка.
- Толькі трэцяя атрымлівае карысць ад паўтору, і толькі па сваёй палітыцы паўтору.
- Перазапіс з заменаю аднаўляе доступ; ачыстка даных прыбірае гэтую магчымасць.
- Праверце свежым злучэннем і звычайнымі праверкамі ідэнтычнасці сервера.