Keystore-fejl på Android VPN: tilmeld igen, lås op eller prøv igen?

Profilen er stadig på listen, certifikatet vises stadig som installeret, og forbind-knappen fejler med en meddelelse, der kun siger «Keystore-fejl» og intet andet. Før du rydder appens lager eller afleverer telefonen, skal du fastslå, hvilken nøgleoperation der fejlede. Tre udfald giver den samme dialog, og de reagerer på tre forskellige handlinger — kun én af dem er destruktiv. Sammenligningen er ti minutter værd, fordi den forkerte gren koster dig den identitet, du prøvede at beholde.

Tre fejl bag én dialog

Den første er godkendelse. Nøglen findes og er gyldig, men brug af den kræver, at brugeren beviser tilstedeværelse — en oplåsning af enheden, biometri eller en udfordring fra arbejdsprofilen. Hvis låsetiden, den registrerede biometri eller profilens tilstand for nylig er ændret, kan nøglebrug fejle, mens selve nøglen er helt i orden.

Den anden er permanent ugyldiggørelse. Noget nøglemateriale ugyldiggøres af platformens politik, når låsemetoden nulstilles, eller den biometriske tilmelding ændres, fordi den binding, der beskyttede den, ikke længere holder. Nøglen kan ikke repareres, og nyt forsøg er ikke en gendannelsesplan; identiteten skal udskiftes gennem den tilmeldingsproces, der udstedte den.

Den tredje er en udbyderfejl: keystore-tjenesten kunne ikke fuldføre operationen lige nu. Det er den klasse, der nogle gange er værd at prøve igen, og den eneste.

Bemærk, at to af de tre ikke er destruktive, og at én slet ikke har nogen løsning på enhedsniveau. Ingen af dem løses ved at slette telefonen, hvilket er det skridt, folk tager først, fordi dialogen ikke giver dem andet at handle på.

Gentilmelding kontra en datarydning

Disse to ser ens ud udefra og er det ikke. Gentilmelding beder det udstedende system om en ny identitet — et nyt certifikat eller en nøgle bundet til denne enhed — og trækker den gamle tilbage. En datarydning sletter appens lagrede tilstand, hvilket kan fjerne referencen til nøglen uden at fjerne nøglen, eller det kan fjerne nøglen og efterlade dig uden bemyndigelse til at genskabe den.

Forskellen er vigtig, fordi ikke-eksporterbare nøgler per design ikke er flytbare. De lever i enhedens keystore understøttet af den hardware eller udbyder, der er tilgængelig, og de er ikke noget, en sikkerhedskopi fanger og en gendannelse genindsætter. Hvis udrulningens identitet er en ikke-eksporterbar nøgle, skal du regne med gentilmelding som gendannelse og på forhånd bekræfte, at du har en godkendt vej til at få den tilmelding — nogle organisationer kræver adgang til et privat netværk til det, hvilket er præcis det, den ødelagte VPN gav.

Så rækkefølgen er: prøv den understøttede godkendelsesvej, afgør derefter, om nøglen er permanent ugyldig, og udskift kun identiteten, hvis den er. Rydning af lageret hører sidst, efter du ved, hvad der bliver genskabt, ikke først fordi det er nemt.

Prøv kun igen, hvad der kan prøves igen

Ældre platformversioner samlede keystore-fejl i én undtagelse, og derfor prøver så mange klienter alt igen. Fra API 33 bærer undtagelsestypen struktur: en numerisk fejl, et flag for forbigående fejl og en politik for nyt forsøg. For en klientudvikler giver politikken for nyt forsøg kun mening, når flaget for forbigående er sandt; en permanent ugyldiggørelse har ingen tidsplan for nyt forsøg, og at hamre på den i en løkke dræner bare batteriet og fylder loggen.

Hvis du diagnosticerer i stedet for at skrive klienten, er den praktiske konsekvens den samme. Identiske fejl ved hvert forsøg udelukker en enkeltstående fejl, men de adskiller ikke en permanent ugyldiggjort nøgle fra en udbyder, der har været utilgængelig i et stykke tid — et udbyderudfald ser nøjagtigt ens ud på det tiende forsøg som på det første. Uden API 33's strukturerede felter skal du behandle gentagelse som en grund til at lede efter et andet signal — fejlkoden, hvis dit build viser den, operatørens status, eller en anden nøgle på samme enhed, der lykkes — og ikke som bevis for, at nøglen er død.

Læs årsagskæden, ikke etiketten

Applikationer pakker den oprindelige undtagelse ind, og den venlige streng i brugerfladen skjuler ofte det ene felt, der afgør grenen. Bevar årsagskæden og tidsstemplet for forsøget: den ydre undtagelse navngiver normalt operationen, og årsagen navngiver nøglens tilstand.

Modstå slutningen om, at to fejlende apps beviser en defekt telefon. Forskellige nøgler kan være understøttet af forskellige udbydere og sikkerhedsniveauer, og en app, der stadig virker, udfører måske slet ikke den samme operation — en signatur, en dekryptering og en nøgleattestering er forskellige anmodninger til den samme tjeneste. KeyStoreException-referencen beskriver de strukturerede felter på nyere API-niveauer og er stedet at kontrollere, hvad dit build faktisk kan rapportere.

Det, der ville understøtte en hardwarekonklusion, er snævrere, end de fleste antager: den samme operation hos den samme udbyder, der fejler på tværs af uafhængige nøgler med en fejl på udbyderniveau snarere end på nøgleniveau. Det er et spørgsmål for platformens diagnostik, ikke for en tråd på et supportforum om en batch enheder.

Hvad du skal notere, mens du beslutter

Noter Android-buildet, klientversionen, den valgte profil, den operation, der fejlede, og om noget for nylig er ændret — en OS-opdatering, en ændring af låseskærmen, et nyt fingeraftryk, en gentilmelding. Noter sekvensen som kontekst snarere end som bevis for årsagen; en låseændring før en nøglefejl er en plausibel korrelation, ikke en demonstration.

Handl derefter på den gren, du fastslog. Forbigående: behold identiteten, brug den understøttede vej til nyt forsøg. Godkendelse påkrævet: fuldfør den understøttede oplåsningsproces og behold den låsepolitik, udrulningen kræver, i stedet for at deaktivere den for at komme forbi en dialog. Permanent ugyldig: udskift og træk identiteten tilbage gennem normal tilmelding.

Afslut med at bevise resultatet på en ny autoriseret forbindelse til en rigtig ressource, mens servervalidering stadig er aktiveret. Alt, der kun virker med lempede certifikatkontroller, har ikke løst nøgleproblemet — det har flyttet det ned i netværkslaget, hvor det senere dukker op med værre symptomer.

• Tre grene: kræver godkendelse, permanent ugyldig, forbigående hos udbyderen.
• Kun den tredje har gavn af nyt forsøg, og kun efter sin egen politik for nyt forsøg.
• Erstatningstilmelding gendanner adgang; en datarydning fjerner muligheden.
• Bekræft med en ny forbindelse og normale serveridentitetskontroller.