Keystore-feil på Android VPN: registrere på nytt, låse opp eller prøve igjen?

Profilen står framleis på lista, sertifikatet blir framleis vist som installert, og kople til-knappen feilar med ei melding som berre seier «Keystore-feil» og ingenting anna. Før du slettar lagringa til appen eller leverer telefonen, må du fastslå kva nøkkeloperasjon som feila. Tre utfall gir same dialogen, og dei svarer på tre ulike handlingar — berre éin av dei er øydeleggjande. Samanlikninga er ti minutt verd, fordi feil grein kostar deg identiteten du prøvde å halde på.

Tre feil bak éin dialog

Den første er autentisering. Nøkkelen finst og er gyldig, men å bruke han krev at brukaren beviser tilstadevere — ei opplåsing av eininga, biometri eller ei utfordring frå arbeidsprofilen. Viss låsetida, den registrerte biometrien eller tilstanden til profilen nyleg er endra, kan nøkkelbruk feile medan nøkkelen sjølv er heilt i orden.

Den andre er varig ugyldiggjering. Noko nøkkelmateriale blir ugyldiggjort av policyen til plattforma når låsemetoden blir nullstilt eller den biometriske registreringa blir endra, fordi bindinga som verna han ikkje lenger gjeld. Nøkkelen kan ikkje reparerast, og eit nytt forsøk er ingen gjenopprettingsplan; identiteten må erstattast gjennom registreringsprosessen som gav han ut.

Den tredje er ein leverandørfeil: keystore-tenesta kunne ikkje fullføre operasjonen akkurat no. Det er klassen det av og til er verd å prøve på nytt, og den einaste.

Legg merke til at to av dei tre ikkje er øydeleggjande, og at éin ikkje har noka løysing på einingnivå i det heile. Ingen av dei blir løyste ved å slette telefonen, som er steget folk tek først fordi dialogen ikkje gir dei noko anna å handle på.

Nyregistrering kontra ein datatømming

Desse to ser like ut utanfrå og er det ikkje. Nyregistrering ber det utsendingande systemet om ein ny identitet — eit nytt sertifikat eller ein nøkkel bunden til denne eininga — og pensjonerer den gamle. Ei datatømming slettar den lagra tilstanden til appen, noko som kan fjerne referansen til nøkkelen utan å fjerne nøkkelen, eller det kan fjerne nøkkelen og la deg stå utan myndigheit til å skape han på nytt.

Skilnaden har noko å seie fordi ikkje-eksporterbare nøklar ved design ikkje er flyttbare. Dei lever i keystore til eininga, støtta av den maskinvara eller leverandøren som er tilgjengeleg, og dei er ikkje noko ein tryggleikskopi fangar og ein gjenoppretting set tilbake. Viss identiteten til utrullinga er ein ikkje-eksporterbar nøkkel, planlegg nyregistrering som gjenoppretting, og stadfest på førehand at du har ein godkjend veg til å skaffe den registreringa — nokre organisasjonar krev tilgang til eit privat nettverk for det, og det er nettopp det den øydelagde VPN-en gav.

Så rekkjefølgja er: prøv den støtta autentiseringsvegen, avgjer deretter om nøkkelen er varig ugyldig, og erstatt identiteten berre viss han er det. Sletting av lagringa høyrer heime sist, etter at du veit kva som blir skapt på nytt, ikkje først fordi det er enkelt.

Prøv på nytt berre det som kan prøvast på nytt

Eldre plattformversjonar samla keystore-feil i éi unntaking, og difor prøver så mange klientar alt på nytt. Frå API 33 ber unntakstypen struktur: ein numerisk feil, eit flagg for forbigåande feil og ein policy for nye forsøk. For ein klientutviklar gir policyen for nye forsøk berre meining når flagget for forbigåande er sant; ei varig ugyldiggjering har ingen plan for nye forsøk, og å hamre på henne i ei løkke tappar berre batteriet og fyller loggen.

Viss du diagnostiserer i staden for å skrive klienten, er den praktiske konsekvensen den same. Identiske feil ved kvart forsøk utelukkar ein eingongfeil, men dei skil ikkje ein varig ugyldiggjort nøkkel frå ein leverandør som har vore utilgjengeleg ei stund — eit leverandøravbrot ser nøyaktig likt ut på det tiande forsøket som på det første. Utan dei strukturerte felta i API 33, handsam gjentaking som ein grunn til å leite etter eit andre signal — feilkoden viss bygget ditt viser han, statusen til operatøren, eller ein annan nøkkel på same eining som lukkast — og ikkje som prov på at nøkkelen er død.

Les årsakskjeda, ikkje etiketten

Applikasjonar pakkar den opphavlege unntakinga inn, og den venlege strengen i grensesnittet skjuler ofte det eine feltet som avgjer greina. Ta vare på årsakskjeda og tidsstempelet for forsøket: den ytre unntakinga namngir vanlegvis operasjonen, og årsaka namngir tilstanden til nøkkelen.

Stå imot slutninga om at to feilande apper provar ein defekt telefon. Ulike nøklar kan støttast av ulike leverandørar og tryggleiksnivå, og ein app som framleis verkar, utfører kanskje ikkje den same operasjonen i det heile — ein signatur, ei dekryptering og ein nøkkelattestasjon er ulike førespurnader til den same tenesta. KeyStoreException-referansen skildrar dei strukturerte felta på nyare API-nivå og er staden å sjekke kva bygget ditt faktisk kan rapportere.

Det som ville støtte ei maskinvarekonklusjon er smalare enn dei fleste trur: den same operasjonen hos den same leverandøren som feilar på tvers av uavhengige nøklar med ein feil på leverandørnivå i staden for nøkkelnivå. Det er eit spørsmål for diagnostikken til plattforma, ikkje for ein tråd på eit støtteforum om ei eininggruppe.

Kva du bør notere medan du bestemmer deg

Noter Android-bygget, klientversjonen, den valde profilen, operasjonen som feila, og om noko er endra nyleg — ein OS-oppdatering, ei endring av låseskjermen, eit nytt fingeravtrykk, ei nyregistrering. Noter sekvensen som kontekst og ikkje som prov på årsak; ei låseendring før ein nøkkelfeil er ein plausibel korrelasjon, ikkje ein demonstrasjon.

Handle deretter etter greina du fastslo. Forbigåande: hald på identiteten, bruk den støtta vegen for nye forsøk. Autentisering kravd: fullfør den støtta opplåsingsflyten og hald på låsepolicyen som utrullinga krev, i staden for å slå han av for å kome forbi ein dialog. Varig ugyldig: erstatt og pensjoner identiteten gjennom vanleg registrering.

Avslutt med å prove resultatet på ei ny autorisert tilkopling, mot ein reell ressurs, med servervalidering framleis aktiv. Alt som berre verkar med lempelege sertifikatkontrollar har ikkje fiksa nøkkelproblemet — det har flytta det ned i nettverkslaget, der det dukkar opp seinare med verre symptom.

• Tre greiner: krev autentisering, varig ugyldig, forbigåande hos leverandøren.
• Berre den tredje har nytte av å prøvast på nytt, og berre etter sin eigen policy for nye forsøk.
• Erstatningsregistrering gjenopprettar tilgang; ei datatømming fjernar moglegheita.
• Verifiser med ei ny tilkopling og normale identitetskontrollar på serveren.