„Keystore“ klaida „Android VPN“: registruoti iš naujo, atrakinti ar bandyti dar kartą?
Trys „Android“ keystore rezultatai reikalauja trijų skirtingų atkūrimo būdų. Palyginkite atrakinimą, perregistravimą ir teikėjo pakartotinį bandymą prieš išvalydami programos saugyklą.
Profilis vis dar sąraše, sertifikatas vis dar rodomas kaip įdiegtas, o prisijungimo mygtukas nepavyksta su pranešimu, kuriame sakoma tik „Keystore klaida“ ir nieko daugiau. Prieš išvalydami programos saugyklą ar atiduodami telefoną, nustatykite, kuri raktų operacija nepavyko. Trys rezultatai sukuria tą patį dialogo langą, ir jie reaguoja į tris skirtingus veiksmus — tik vienas jų yra destruktyvus. Palyginimas vertas dešimties minučių, nes neteisinga šaka kainuoja tapatybę, kurią bandėte išsaugoti.
Trys gedimai už vieno dialogo
Pirmasis yra autentifikavimas. Raktas egzistuoja ir galioja, bet jo naudojimas reikalauja, kad vartotojas įrodytų buvimą — įrenginio atrakinimą, biometriją ar darbo profilio iššūkį. Jei užrakinimo laikas, užregistruota biometrija ar profilio būsena neseniai pasikeitė, rakto naudojimas gali nepavykti, nors pats raktas yra visiškai tvarkingas.
Antrasis yra negrįžtamas panaikinimas. Kai kurias raktų medžiagas platformos politika panaikina, kai atstatomas užrakinimo būdas ar pasikeičia biometrinė registracija, nes juos saugęs ryšys nebegalioja. Rakto sutaisyti neįmanoma, o pakartotinis bandymas nėra atkūrimo planas; tapatybė turi būti pakeista per registracijos procesą, kuris ją išdavė.
Trečiasis yra teikėjo gedimas: keystore paslauga dabar negalėjo užbaigti operacijos. Tai klasė, kurią kartais verta kartoti, ir vienintelė.
| 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 |
Atkreipkite dėmesį, kad du iš trijų nėra destruktyvūs, o vienas neturi jokio sprendimo įrenginio lygmeniu. Nė vienas jų neišsprendžiamas ištrinant telefoną, o būtent šį žingsnį žmonės daro pirmiausia, nes dialogas jiems nieko daugiau nesiūlo.
Perregistravimas arba duomenų išvalymas
Šie du iš išorės atrodo panašiai ir nėra. Perregistravimas prašo išdavusios sistemos naujos tapatybės — naujo sertifikato ar rakto, susieto su šiuo įrenginiu — ir atsisako senosios. Duomenų išvalymas ištrina išsaugotą programos būseną, todėl gali pašalinti nuorodą į raktą nepašalindamas rakto, arba gali pašalinti raktą ir palikti jus be teisės jį atkurti.
Skirtumas svarbus, nes neeksportuojami raktai pagal projektą nėra perkeliami. Jie gyvena įrenginio keystore, palaikomi bet kokios prieinamos aparatinės įrangos ar teikėjo, ir tai nėra dalykas, kurį atsarginė kopija sugriebtų, o atkūrimas sugrąžintų. Jei diegimo tapatybė yra neeksportuojamas raktas, planuokite perregistravimą kaip atkūrimą ir iš anksto patvirtinkite, kad turite patvirtintą kelią tai registracijai gauti — kai kurios organizacijos tam reikalauja prieigos prie privataus tinklo, o būtent tai ir teikė sugedęs VPN.
Taigi tvarka tokia: išbandykite palaikomą autentifikavimo kelią, tada nustatykite, ar raktas negrįžtamai negalioja, ir pakeiskite tapatybę tik jei taip. Saugyklos išvalymas yra paskutinis, kai žinote, kas bus sukurta iš naujo, o ne pirmas todėl, kad tai lengva.
Kartokite tik tai, ką galima kartoti
Senesnės platformos versijos keystore klaidas sujungdavo į vieną išimtį, todėl tiek daug klientų kartoja viską. Nuo API 33 išimties tipas turi struktūrą: skaitinę klaidą, laikino gedimo žymę ir pakartotinio bandymo politiką. Kliento kūrėjui pakartotinio bandymo politika prasminga tik tada, kai laikinumo žymė teisinga; negrįžtamas panaikinimas neturi pakartotinio bandymo grafiko, o jo kalimas cikle tik išeikvoja bateriją ir užpildo žurnalą.
Jei diagnozuojate, o ne rašote klientą, praktinė pasekmė ta pati. Identiški gedimai kiekvieno bandymo metu pašalina vienkartinį sutrikimą, bet neatskiria negrįžtamai panaikinto rakto nuo teikėjo, kuris jau kurį laiką nepasiekiamas — teikėjo sutrikimas dešimtą kartą atrodo lygiai taip pat kaip pirmą. Be API 33 struktūrizuotų laukų, kartojimą laikykite priežastimi ieškoti antro signalo — klaidos kodo, jei jūsų build jį rodo, operatoriaus būsenos ar kito rakto tame pačiame įrenginyje sėkmės — o ne įrodymu, kad raktas miręs.
Skaitykite priežasčių grandinę, o ne etiketę
Programos apgaubia pirminę išimtį, o draugiška sąsajos eilutė dažnai paslepia vienintelį lauką, kuris nusprendžia šaką. Išsaugokite priežasčių grandinę ir bandymo laiko žymą: išorinė išimtis paprastai įvardija operaciją, o priežastis įvardija rakto būseną.
Priešinkitės išvadai, kad dvi nepavykstančios programos įrodo sugedusį telefoną. Skirtingi raktai gali būti palaikomi skirtingų teikėjų ir saugumo lygių, o vis dar veikianti programa gali visiškai neatlikti tos pačios operacijos — parašas, iššifravimas ir rakto patvirtinimas yra skirtingi prašymai tai pačiai paslaugai. KeyStoreException nuoroda aprašo struktūrizuotus laukus naujesniuose API lygiuose ir yra vieta, kur patikrinti, ką jūsų build iš tikrųjų gali pranešti.
Tai, kas pagrįstų aparatinės įrangos išvadą, yra siauriau, nei dauguma mano: ta pati operacija, pas tą patį teikėją, nepavyksta nepriklausomuose raktuose su teikėjo lygmens, o ne rakto lygmens klaida. Tai platformos diagnostikos klausimas, o ne pagalbos forumo tema apie įrenginių partiją.
Ką užrašyti, kol sprendžiate
Užrašykite Android build, kliento versiją, pasirinktą profilį, nepavykusią operaciją ir ar kas nors neseniai pasikeitė — OS atnaujinimas, užrakinimo ekrano pakeitimas, naujas piršto atspaudas, perregistravimas. Užrašykite seką kaip kontekstą, o ne kaip priežasties įrodymą; užrakinimo pakeitimas prieš rakto gedimą yra tikėtina koreliacija, o ne demonstracija.
Tada veikite pagal nustatytą šaką. Laikinas: išsaugokite tapatybę, naudokite palaikomą pakartotinio bandymo kelią. Reikia autentifikavimo: užbaikite palaikomą atrakinimo eigą ir išlaikykite diegimo reikalaujamą užrakinimo politiką, o ne išjunkite ją, kad apeitumėte dialogą. Negrįžtamai negaliojantis: pakeiskite ir atsisakykite tapatybės per įprastą registraciją.
Užbaikite įrodydami rezultatą naujame leistame ryšyje, su tikru ištekliumi, kai serverio patikra vis dar įjungta. Viskas, kas veikia tik su susilpnintomis sertifikatų patikromis, neišsprendė rakto problemos — tai perkėlė ją į tinklo sluoksnį, kur ji vėliau pasireikš blogesniais simptomais.
- Trys šakos: reikia autentifikavimo, negrįžtamai negaliojantis, laikinas pas teikėją.
- Tik trečiasis gauna naudos iš pakartotinio bandymo, ir tik pagal savo pakartotinio bandymo politiką.
- Pakaitinė registracija atkuria prieigą; duomenų išvalymas pašalina šią galimybę.
- Patikrinkite nauju ryšiu ir įprastomis serverio tapatybės patikromis.