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

Profilen står fortsatt på listen, sertifikatet vises fortsatt som installert, og koble til-knappen feiler med en melding som bare sier «Keystore-feil» og ingenting annet. Før du sletter appens lagring eller leverer telefonen, må du fastslå hvilken nøkkeloperasjon som feilet. Tre utfall gir samme dialog, og de svarer på tre ulike handlinger — bare én av dem er destruktiv. Sammenligningen er verdt ti minutter, fordi feil gren koster deg identiteten du prøvde å beholde.

Tre feil bak én dialog

Den første er autentisering. Nøkkelen finnes og er gyldig, men å bruke den krever at brukeren beviser tilstedeværelse — en opplåsing av enheten, biometri eller en utfordring fra arbeidsprofilen. Hvis låsetiden, den registrerte biometrien eller profilens tilstand nylig er endret, kan nøkkelbruk feile mens nøkkelen selv er helt i orden.

Den andre er permanent ugyldiggjøring. Noe nøkkelmateriale ugyldiggjøres av plattformens policy når låsemetoden tilbakestilles eller den biometriske registreringen endres, fordi bindingen som beskyttet den ikke lenger gjelder. Nøkkelen kan ikke repareres, og et nytt forsøk er ingen gjenopprettingsplan; identiteten må erstattes gjennom registreringsprosessen som utstedte den.

Den tredje er en leverandørfeil: keystore-tjenesten kunne ikke fullføre operasjonen akkurat nå. Det er klassen det noen ganger er verdt å prøve på nytt, og den eneste.

Legg merke til at to av de tre ikke er destruktive, og at én ikke har noen løsning på enhetsnivå i det hele tatt. Ingen av dem løses ved å slette telefonen, som er trinnet folk tar først fordi dialogen ikke gir dem noe annet å handle på.

Nyregistrering kontra en datatømming

Disse to ser like ut utenfra og er det ikke. Nyregistrering ber det utstedende systemet om en ny identitet — et nytt sertifikat eller en nøkkel bundet til denne enheten — og pensjonerer den gamle. En datatømming sletter appens lagrede tilstand, noe som kan fjerne referansen til nøkkelen uten å fjerne nøkkelen, eller det kan fjerne nøkkelen og la deg stå uten myndighet til å gjenskape den.

Forskjellen betyr noe fordi ikke-eksporterbare nøkler ved design ikke er flyttbare. De lever i enhetens keystore, støttet av den maskinvaren eller leverandøren som er tilgjengelig, og de er ikke noe en sikkerhetskopi fanger og en gjenoppretting setter tilbake. Hvis utrullingens identitet er en ikke-eksporterbar nøkkel, planlegg nyregistrering som gjenoppretting, og bekreft på forhånd at du har en godkjent vei til å skaffe den registreringen — noen organisasjoner krever tilgang til et privat nettverk for det, og det er nettopp det den ødelagte VPN-en ga.

Så rekkefølgen er: prøv den støttede autentiseringsveien, avgjør deretter om nøkkelen er permanent ugyldig, og erstatt identiteten bare hvis den er det. Sletting av lagringen hører hjemme sist, etter at du vet hva som blir gjenskapt, ikke først fordi det er enkelt.

Prøv på nytt bare det som kan prøves på nytt

Eldre plattformversjoner samlet keystore-feil i én unntakelse, og derfor prøver så mange klienter alt på nytt. Fra API 33 bærer unntakstypen struktur: en numerisk feil, et flagg for forbigående feil og en policy for nye forsøk. For en klientutvikler gir policyen for nye forsøk bare mening når flagget for forbigående er sant; en permanent ugyldiggjøring har ingen plan for nye forsøk, og å hamre på den i en løkke tapper bare batteriet og fyller loggen.

Hvis du diagnostiserer i stedet for å skrive klienten, er den praktiske konsekvensen den samme. Identiske feil ved hvert forsøk utelukker en engangsfeil, men de skiller ikke en permanent ugyldiggjort nøkkel fra en leverandør som har vært utilgjengelig en stund — et leverandørutfall ser nøyaktig likt ut på det tiende forsøket som på det første. Uten API 33s strukturerte felt, behandle gjentakelse som en grunn til å lete etter et andre signal — feilkoden hvis bygget ditt viser den, operatørens status, eller en annen nøkkel på samme enhet som lykkes — og ikke som bevis for at nøkkelen er død.

Les årsakskjeden, ikke etiketten

Applikasjoner pakker den opprinnelige unntakelsen inn, og den vennlige strengen i grensesnittet skjuler ofte det ene feltet som avgjør grenen. Bevar årsakskjeden og tidsstempelet for forsøket: den ytre unntakelsen navngir vanligvis operasjonen, og årsaken navngir nøkkelens tilstand.

Motstå slutningen om at to feilende apper beviser en defekt telefon. Ulike nøkler kan støttes av ulike leverandører og sikkerhetsnivåer, og en app som fortsatt virker, utfører kanskje ikke den samme operasjonen i det hele tatt — en signatur, en dekryptering og en nøkkelattestering er ulike forespørsler til den samme tjenesten. KeyStoreException-referansen beskriver de strukturerte feltene på nyere API-nivåer og er stedet å sjekke hva bygget ditt faktisk kan rapportere.

Det som ville støtte en maskinvarekonklusjon er smalere enn de fleste antar: den samme operasjonen hos den samme leverandøren som feiler på tvers av uavhengige nøkler med en feil på leverandørnivå i stedet for nøkkelnivå. Det er et spørsmål for plattformens diagnostikk, ikke for en tråd på et støtteforum om en enhetsgruppe.

Hva du bør notere mens du bestemmer deg

Noter Android-bygget, klientversjonen, den valgte profilen, operasjonen som feilet, og om noe er endret nylig — en OS-oppdatering, en endring av låseskjermen, et nytt fingeravtrykk, en nyregistrering. Noter sekvensen som kontekst og ikke som bevis på årsak; en låseendring før en nøkkelfeil er en plausibel korrelasjon, ikke en demonstrasjon.

Handle deretter etter grenen du fastslo. Forbigående: behold identiteten, bruk den støttede veien for nye forsøk. Autentisering kreves: fullfør den støttede opplåsingsflyten og behold låsepolicyen som utrullingen krever, i stedet for å slå den av for å komme forbi en dialog. Permanent ugyldig: erstatt og pensjoner identiteten gjennom vanlig registrering.

Avslutt med å bevise resultatet på en ny autorisert tilkobling, mot en reell ressurs, med servervalidering fortsatt aktiv. Alt som bare virker med lempede sertifikatkontroller har ikke fikset nøkkelproblemet — det har flyttet det ned i nettverkslaget, der det dukker opp senere med verre symptomer.

• Tre grener: krever autentisering, permanent ugyldig, forbigående hos leverandøren.
• Bare den tredje har nytte av å prøves på nytt, og bare etter sin egen policy for nye forsøk.
• Erstatningsregistrering gjenoppretter tilgang; en datatømming fjerner muligheten.
• Verifiser med en ny tilkobling og normale identitetskontroller på serveren.