Error de Keystore a l'Android VPN: tornar a registrar, desbloquejar o reintentar?

El perfil encara apareix a la llista, el certificat encara es mostra com a instal·lat i el botó de connexió falla amb un missatge que només diu «Error de Keystore» i res més. Abans d'esborrar l'emmagatzematge de l'aplicació o de lliurar el telèfon, establiu quina operació de clau ha fallat. Tres resultats produeixen el mateix diàleg i responen a tres accions diferents — només una de les quals és destructiva. La comparació val deu minuts, perquè la branca equivocada us costa la identitat que intentàveu conservar.

Tres fallades darrere d'un sol diàleg

La primera és l'autenticació. La clau existeix i és vàlida, però utilitzar-la exigeix que l'usuari demostri presència: un desbloqueig del dispositiu, una biometria o un repte del perfil de treball. Si el temps d'espera del bloqueig, les biometries registrades o l'estat del perfil han canviat recentment, l'ús de la clau pot fallar mentre la clau mateixa és perfectament correcta.

La segona és la invalidació permanent. La política de la plataforma invalida part del material de clau quan es restableix el mètode de bloqueig o canvia el registre biomètric, perquè la vinculació que la protegia ja no es manté. La clau no es pot reparar i reintentar-ho no és un pla de recuperació; la identitat s'ha de substituir mitjançant el procés de registre que la va emetre.

La tercera és una fallada del proveïdor: el servei de keystore no ha pogut completar l'operació ara mateix. Aquesta és la classe que de vegades val la pena reintentar, i l'única.

Fixeu-vos que dues de les tres no són destructives i una no té cap solució a nivell de dispositiu. Cap d'elles no es resol esborrant el telèfon, que és el pas que la gent fa primer perquè el diàleg no els ofereix res més per actuar.

Reinregistració enfront d'un esborrat de dades

Aquestes dues semblen iguals des de fora i no ho són. La reinregistració demana al sistema emissor una identitat nova — un certificat o una clau nous vinculats a aquest dispositiu — i retira l'antiga. Un esborrat de dades suprimeix l'estat desat de l'aplicació, cosa que pot treure la referència a la clau sense treure la clau, o pot treure la clau i deixar-vos sense autoritat per recrear-la.

La distinció importa perquè les claus no exportables, per disseny, no són portables. Viuen al keystore del dispositiu, amb el suport del maquinari o proveïdor disponible, i no són una cosa que una còpia de seguretat capturi i una restauració reinstauri. Si la identitat del desplegament és una clau no exportable, planifiqueu la reinregistració com a recuperació i confirmeu per endavant que teniu una via aprovada per obtenir aquest registre: algunes organitzacions exigeixen accés a la xarxa privada per fer-ho, que és exactament el que oferia la VPN trencada.

Així doncs, l'ordre és: proveu la via d'autenticació compatible, determineu després si la clau és permanentment invàlida i substituïu la identitat només si ho és. Esborrar l'emmagatzematge va al final, després de saber què es recrearà, no primer perquè és fàcil.

Reintenteu només el que és reintentable

Les versions antigues de la plataforma agrupaven els errors de keystore en una sola excepció, i per això tants clients ho reintenten tot. A partir de l'API 33 el tipus d'excepció porta estructura: un error numèric, un indicador de fallada transitòria i una política de reintent. Per a un desenvolupador de clients, la política de reintent només té sentit quan l'indicador de transitorietat és cert; una invalidació permanent no té calendari de reintents, i martellejar-la en bucle només esgota la bateria i omple el registre.

Si diagnostiqueu en lloc d'escriure el client, la conseqüència pràctica és la mateixa. Les fallades idèntiques a cada intent descarten una fallada puntual, però no separen una clau invalidada permanentment d'un proveïdor que fa temps que no està disponible: una caiguda del proveïdor es veu exactament igual al desè reintent que al primer. Sense els camps estructurats de l'API 33, tracteu la repetició com un motiu per buscar un segon senyal — el codi d'error si la vostra compilació l'exposa, l'estat de l'operador o una altra clau al mateix dispositiu que funciona — i no com a prova que la clau és morta.

Llegiu la cadena de causes, no l'etiqueta

Les aplicacions embolcallen l'excepció original, i la cadena amable de la interfície sovint amaga l'únic camp que decideix la branca. Conserveu la cadena de causes i la marca temporal de l'intent: l'excepció exterior normalment anomena l'operació, i la causa anomena l'estat de la clau.

Resistiu la inferència que dues aplicacions que fallen proven un telèfon defectuós. Claus diferents poden tenir proveïdors i nivells de seguretat diferents, i una aplicació que encara funciona potser no executa la mateixa operació: una signatura, un desxifrat i una atestació de clau són peticions diferents al mateix servei. referència de KeyStoreException descriu els camps estructurats en nivells d'API més nous i és el lloc on comprovar què pot informar realment la vostra compilació.

El que donaria suport a una conclusió de maquinari és més estret del que la majoria suposa: la mateixa operació, amb el mateix proveïdor, fallant en claus independents amb un error de nivell de proveïdor i no de nivell de clau. Això és una pregunta per al diagnòstic de la plataforma, no per a un fil d'un fòrum de suport sobre un lot de dispositius.

Què cal registrar mentre decidiu

Registreu la compilació d'Android, la versió del client, el perfil seleccionat, l'operació que ha fallat i si alguna cosa ha canviat recentment: una actualització del sistema, un canvi de pantalla de bloqueig, una empremta nova, una reinregistració. Registreu la seqüència com a context i no com a prova de la causa; un canvi de bloqueig abans d'una fallada de clau és una correlació plausible, no una demostració.

Després actueu segons la branca que hàgiu establert. Transitòria: conserveu la identitat, feu servir la via de reintent compatible. Cal autenticació: completeu el flux de desbloqueig compatible i manteniu la política de bloqueig que exigeix el desplegament en lloc de desactivar-la per passar un diàleg. Permanentment invàlida: substituïu i retireu la identitat mitjançant el registre normal.

Acabeu demostrant el resultat en una connexió autoritzada nova, cap a un recurs real, amb la validació del servidor encara activada. Qualsevol cosa que només funcioni amb les comprovacions de certificats relaxades no ha arreglat el problema de la clau: l'ha traslladat a la capa de xarxa, on apareixerà més tard amb símptomes pitjors.

• Tres branques: cal autenticació, permanentment invàlida, transitòria del proveïdor.
• Només la tercera es beneficia de reintentar, i només segons la seva política de reintent.
• La reinregistració substitutiva restaura l'accés; un esborrat de dades elimina l'opció.
• Verifiqueu amb una connexió nova i comprovacions d'identitat de servidor normals.