Keystore-fout op Android VPN: opnieuw registreren, ontgrendelen of opnieuw proberen?

Het profiel staat nog in de lijst, het certificaat wordt nog als geïnstalleerd getoond, en de verbindknop faalt met een bericht dat alleen «Keystore-fout» zegt en niets anders. Voordat u de app-opslag wist of de telefoon inlevert, stelt u vast welke sleutelbewerking is mislukt. Drie uitkomsten geven dezelfde dialoog, en ze reageren op drie verschillende acties — slechts één ervan is destructief. De vergelijking is tien minuten waard, want de verkeerde tak kost u de identiteit die u probeerde te behouden.

Drie fouten achter één dialoog

De eerste is authenticatie. De sleutel bestaat en is geldig, maar het gebruik ervan vereist dat de gebruiker aanwezigheid bewijst — een ontgrendeling van het toestel, biometrie of een uitdaging van het werkprofiel. Als de vergrendelingstijd, de geregistreerde biometrie of de profielstatus onlangs zijn veranderd, kan sleutelgebruik mislukken terwijl de sleutel zelf volkomen in orde is.

De tweede is blijvende ongeldigmaking. Bepaald sleutelmateriaal wordt door het platformbeleid ongeldig gemaakt wanneer de vergrendelmethode wordt gereset of de biometrische registratie verandert, omdat de binding die het beschermde niet meer geldt. De sleutel kan niet worden gerepareerd en opnieuw proberen is geen herstelplan; de identiteit moet worden vervangen via het registratieproces dat hem heeft uitgegeven.

De derde is een providerstoring: de keystore-dienst kon de bewerking nu niet voltooien. Dat is de klasse die soms de moeite van een nieuwe poging waard is, en de enige.

Merk op dat twee van de drie niet destructief zijn en één op toestelniveau helemaal geen oplossing heeft. Geen ervan wordt opgelost door de telefoon te wissen, de stap die mensen als eerste nemen omdat de dialoog hun niets anders biedt.

Opnieuw registreren versus een datawis

Deze twee lijken van buiten op elkaar en zijn het niet. Opnieuw registreren vraagt het uitgevende systeem om een nieuwe identiteit — een nieuw certificaat of een sleutel die aan dit toestel is gebonden — en zet de oude op rust. Een datawis verwijdert de opgeslagen staat van de app, wat de verwijzing naar de sleutel kan weghalen zonder de sleutel weg te halen, of het kan de sleutel weghalen en u achterlaten zonder de bevoegdheid om hem opnieuw te maken.

Het onderscheid is belangrijk omdat niet-exporteerbare sleutels per ontwerp niet overdraagbaar zijn. Ze leven in de keystore van het toestel, gesteund door de beschikbare hardware of provider, en ze zijn niet iets wat een back-up vastlegt en een herstel terugzet. Als de identiteit van de inzet een niet-exporteerbare sleutel is, plan dan opnieuw registreren als het herstel, en bevestig vooraf dat u een goedgekeurde route hebt om die registratie te verkrijgen — sommige organisaties eisen daarvoor toegang tot een particulier netwerk, en dat is precies wat de kapotte VPN bood.

De volgorde is dus: probeer het ondersteunde authenticatiepad, bepaal daarna of de sleutel blijvend ongeldig is, en vervang de identiteit alleen als dat zo is. Het wissen van de opslag hoort achteraan, nadat u weet wat er opnieuw wordt aangemaakt, niet vooraan omdat het makkelijk is.

Probeer alleen opnieuw wat opnieuw kan

Oudere platformversies stopten keystore-fouten in één uitzondering, en daarom proberen zoveel clients alles opnieuw. Vanaf API 33 draagt het uitzonderingstype structuur: een numerieke fout, een vlag voor tijdelijke storing en een beleid voor nieuwe pogingen. Voor een clientontwikkelaar is het beleid voor nieuwe pogingen alleen zinvol als de vlag voor tijdelijkheid waar is; blijvende ongeldigmaking heeft geen schema voor nieuwe pogingen, en er in een lus op hameren put alleen de batterij uit en vult het log.

Als u diagnosticeert in plaats van de client te schrijven, is het praktische gevolg hetzelfde. Identieke fouten bij elke poging sluiten een eenmalige storing uit, maar ze scheiden een blijvend ongeldig gemaakte sleutel niet van een provider die al een tijd niet beschikbaar is — een providerstoring ziet er bij de tiende poging precies hetzelfde uit als bij de eerste. Zonder de gestructureerde velden van API 33 behandelt u herhaling als reden om een tweede signaal te zoeken — de foutcode als uw build die toont, de status van de operator, of een andere sleutel op hetzelfde toestel die wel lukt — en niet als bewijs dat de sleutel dood is.

Lees de oorzaakketen, niet het label

Applicaties wikkelen de oorspronkelijke uitzondering in, en de vriendelijke tekst in de interface verbergt vaak het enige veld dat de tak bepaalt. Bewaar de oorzaakketen en de tijdstempel van de poging: de buitenste uitzondering noemt meestal de bewerking, en de oorzaak noemt de toestand van de sleutel.

Verzet u tegen de gevolgtrekking dat twee falende apps een defect toestel bewijzen. Verschillende sleutels kunnen door verschillende providers en beveiligingsniveaus worden gesteund, en een app die nog werkt voert misschien helemaal niet dezelfde bewerking uit — een handtekening, een ontsleuteling en een sleutelattestatie zijn verschillende verzoeken aan dezelfde dienst. KeyStoreException-referentie beschrijft de gestructureerde velden op nieuwere API-niveaus en is de plek om te controleren wat uw build echt kan melden.

Wat een hardwareconclusie zou steunen is smaller dan de meeste mensen aannemen: dezelfde bewerking bij dezelfde provider die bij onafhankelijke sleutels faalt met een fout op providerniveau en niet op sleutelniveau. Dat is een vraag voor de diagnostiek van het platform, niet voor een draadje op een supportforum over een partij toestellen.

Wat u vastlegt terwijl u beslist

Leg de Android-build, de clientversie, het gekozen profiel, de mislukte bewerking en of er onlangs iets is veranderd vast — een OS-update, een wijziging van het vergrendelscherm, een nieuwe vingerafdruk, een nieuwe registratie. Leg de volgorde vast als context en niet als bewijs van de oorzaak; een vergrendelingswijziging voor een sleutelfout is een plausibele correlatie, geen demonstratie.

Handel daarna volgens de tak die u hebt vastgesteld. Tijdelijk: behoud de identiteit, gebruik het ondersteunde pad voor nieuwe pogingen. Authenticatie vereist: rond de ondersteunde ontgrendelingsstroom af en behoud het vergrendelingsbeleid dat de inzet vereist in plaats van het uit te schakelen om een dialoog te passeren. Blijvend ongeldig: vervang en zet de identiteit op rust via normale registratie.

Sluit af door het resultaat te bewijzen op een nieuwe geautoriseerde verbinding, naar een echte bron, met servervalidatie nog steeds aan. Alles wat alleen werkt met versoepelde certificaatcontroles heeft het sleutelprobleem niet opgelost — het heeft het naar de netwerklaag verplaatst, waar het later met ergere symptomen opduikt.

• Drie takken: authenticatie vereist, blijvend ongeldig, tijdelijk bij de provider.
• Alleen de derde heeft baat bij een nieuwe poging, en alleen volgens zijn eigen beleid voor nieuwe pogingen.
• Vervangende registratie herstelt de toegang; een datawis haalt de optie weg.
• Verifieer met een nieuwe verbinding en normale identiteitscontroles op de server.