Keystore kļūda Android VPN: reģistrēties no jauna, atslēgt vai mēģināt vēlreiz?

Profils joprojām ir sarakstā, sertifikāts joprojām tiek rādīts kā instalēts, un savienošanas poga neizdodas ar ziņojumu, kas saka tikai «Keystore kļūda» un neko citu. Pirms lietotnes krātuves dzēšanas vai tālruņa nodošanas noskaidrojiet, kura atslēgas darbība neizdevās. Trīs iznākumi rada to pašu dialogu, un tie reaģē uz trim dažādām darbībām — tikai viena no tām ir postoša. Salīdzinājums ir desmit minūšu vērts, jo nepareizais zars jums izmaksā identitāti, kuru centāties saglabāt.

Trīs kļūmes aiz viena dialoga

Pirmais ir autentifikācija. Atslēga pastāv un ir derīga, taču tās lietošana prasa, lai lietotājs pierādītu klātbūtni — ierīces atslēgšanu, biometriju vai darba profila izaicinājumu. Ja bloķēšanas taimauts, reģistrētā biometrija vai profila stāvoklis nesen ir mainījies, atslēgas lietošana var neizdoties, lai gan pati atslēga ir pilnīgi kārtībā.

Otrais ir neatgriezeniska anulēšana. Dažus atslēgas materiālus platformas politika anulē, kad tiek atiestatīta bloķēšanas metode vai mainās biometriskā reģistrācija, jo saite, kas tos aizsargāja, vairs nav spēkā. Atslēgu nevar salabot, un atkārtots mēģinājums nav atkopšanas plāns; identitāte jāaizstāj ar reģistrācijas procesu, kas to izdeva.

Trešais ir pakalpojumu sniedzēja kļūme: keystore pakalpojums tagad nevarēja pabeigt darbību. Šī ir klase, kuru dažkārt ir vērts atkārtot, un vienīgā.

Ievērojiet, ka divi no trim nav postoši un vienam ierīces līmenī vispār nav risinājuma. Neviens no tiem netiek atrisināts, dzēšot tālruni, un tieši šo soli cilvēki sper vispirms, jo dialogs viņiem neko citu nepiedāvā.

Atkārtota reģistrācija pret datu dzēšanu

Šie divi no ārpuses izskatās līdzīgi un nav. Atkārtota reģistrācija lūdz izdevējsistēmu jaunu identitāti — svaigu sertifikātu vai atslēgu, kas piesaistīta šai ierīcei — un pensionē veco. Datu dzēšana izdzēš lietotnes saglabāto stāvokli, kas var noņemt atsauci uz atslēgu, bet ne pašu atslēgu, vai arī var noņemt atslēgu un atstāt jūs bez pilnvarām to atjaunot.

Atšķirība ir svarīga, jo neeksportējamas atslēgas pēc konstrukcijas nav pārvietojamas. Tās dzīvo ierīces keystore, balstoties uz pieejamo aparatūru vai pakalpojumu sniedzēju, un tās nav kaut kas, ko rezerves kopija satver un atjaunošana atgriež. Ja izvietojuma identitāte ir neeksportējama atslēga, plānojiet atkārtotu reģistrāciju kā atkopšanu un iepriekš apstipriniet, ka jums ir apstiprināts ceļš šīs reģistrācijas iegūšanai — dažas organizācijas tam pieprasa piekļuvi privātajam tīklam, un tieši to nodrošināja sabojātais VPN.

Tātad secība ir šāda: izmēģiniet atbalstīto autentifikācijas ceļu, pēc tam nosakiet, vai atslēga ir neatgriezeniski nederīga, un aizstājiet identitāti tikai tad, ja tā ir. Krātuves dzēšana ir pēdējā, pēc tam, kad zināt, kas tiks izveidots no jauna, nevis pirmā tāpēc, ka tas ir viegli.

Atkārtojiet tikai to, ko var atkārtot

Vecākas platformas versijas keystore kļūdas apvienoja vienā izņēmumā, tāpēc tik daudz klientu atkārto visu. No API 33 izņēmuma tips nes struktūru: skaitlisku kļūdu, pārejošas kļūmes karodziņu un atkārtošanas politiku. Klienta izstrādātājam atkārtošanas politikai ir jēga tikai tad, ja pārejošuma karodziņš ir patiess; neatgriezeniskai anulēšanai nav atkārtošanas grafika, un tās dauzīšana cilpā tikai iztukšo akumulatoru un piepilda žurnālu.

Ja jūs diagnosticējat, nevis rakstāt klientu, praktiskās sekas ir tādas pašas. Identiskas kļūmes katrā mēģinājumā izslēdz vienreizēju traucējumu, taču tās neatdala neatgriezeniski anulētu atslēgu no pakalpojumu sniedzēja, kas jau kādu laiku nav pieejams — pakalpojumu sniedzēja pārtraukums desmitajā mēģinājumā izskatās tieši tāpat kā pirmajā. Bez API 33 strukturētajiem laukiem uzskatiet atkārtošanu par iemeslu meklēt otru signālu — kļūdas kodu, ja jūsu build to parāda, operatora statusu vai citas atslēgas panākumus tajā pašā ierīcē — nevis par pierādījumu, ka atslēga ir mirusi.

Lasiet cēloņu ķēdi, nevis etiķeti

Lietotnes ietin sākotnējo izņēmumu, un draudzīgā saskarnes virkne bieži slēpj vienīgo lauku, kas nosaka zaru. Saglabājiet cēloņu ķēdi un mēģinājuma laika zīmi: ārējais izņēmums parasti nosauc darbību, un cēlonis nosauc atslēgas stāvokli.

Pretojieties secinājumam, ka divas nespējīgas lietotnes pierāda bojātu tālruni. Dažādas atslēgas var balstīt dažādi pakalpojumu sniedzēji un drošības līmeņi, un lietotne, kas vēl darbojas, var vispār neveikt to pašu darbību — paraksts, atšifrēšana un atslēgas apliecinājums ir dažādi pieprasījumi vienam un tam pašam pakalpojumam. KeyStoreException atsauce apraksta strukturētos laukus jaunākos API līmeņos un ir vieta, kur pārbaudīt, ko jūsu build patiešām var ziņot.

Tas, kas atbalstītu aparatūras secinājumu, ir šaurāks, nekā vairums pieņem: tā pati darbība, pie tā paša pakalpojumu sniedzēja, neizdodas neatkarīgās atslēgās ar pakalpojumu sniedzēja līmeņa, nevis atslēgas līmeņa kļūdu. Tas ir jautājums platformas diagnostikai, nevis atbalsta foruma pavedienam par ierīču partiju.

Ko pierakstīt, kamēr izlemjat

Pierakstiet Android build, klienta versiju, izvēlēto profilu, neizdevušos darbību un to, vai nesen kaut kas mainījās — OS atjauninājums, bloķēšanas ekrāna izmaiņas, jauns pirksta nospiedums, atkārtota reģistrācija. Pierakstiet secību kā kontekstu, nevis kā cēloņa pierādījumu; bloķēšanas izmaiņas pirms atslēgas kļūmes ir ticama korelācija, nevis demonstrācija.

Pēc tam rīkojieties saskaņā ar noteikto zaru. Pārejošs: saglabājiet identitāti, izmantojiet atbalstīto atkārtošanas ceļu. Nepieciešama autentifikācija: pabeidziet atbalstīto atslēgšanas plūsmu un saglabājiet izvietojuma prasīto bloķēšanas politiku, nevis atslēdziet to, lai apietu dialogu. Neatgriezeniski nederīgs: aizstājiet un pensionējiet identitāti ar parastu reģistrāciju.

Pabeidziet, pierādot rezultātu jaunā atļautā savienojumā ar reālu resursu, kamēr servera validācija joprojām ir ieslēgta. Viss, kas darbojas tikai ar mīkstinātām sertifikātu pārbaudēm, nav novērsis atslēgas problēmu — tas ir pārvietojis to uz tīkla slāni, kur tā vēlāk parādīsies ar sliktākiem simptomiem.

• Trīs zari: nepieciešama autentifikācija, neatgriezeniski nederīgs, pārejošs pie pakalpojumu sniedzēja.
• Tikai trešais gūst labumu no atkārtošanas, un tikai saskaņā ar savu atkārtošanas politiku.
• Aizvietošanas reģistrācija atjauno piekļuvi; datu dzēšana noņem šo iespēju.
• Pārbaudiet ar jaunu savienojumu un parastām servera identitātes pārbaudēm.