Erro de Keystore en Android VPN: volver rexistrar, desbloquear ou reintentar?
Tres resultados do keystore de Android requiren tres recuperacións distintas. Compare o desbloqueo, o novo rexistro e o reintento do provedor antes de borrar o almacenamento da aplicación.
O perfil segue na lista, o certificado aínda aparece como instalado e o botón de conexión falla cunha mensaxe que só di «Erro de Keystore» e nada máis. Antes de borrar o almacenamento da aplicación ou de entregar o teléfono, determine que operación de clave fallou. Tres resultados producen o mesmo diálogo e responden a tres accións distintas, das cales só unha é destrutiva. A comparación merece dez minutos porque a rama equivocada custa a identidade que tentaba conservar.
Tres fallos detrás dun só diálogo
O primeiro é a autenticación. A clave existe e é válida, pero usala esixe que o usuario demostre presenza: un desbloqueo do dispositivo, unha biometría ou un desafío do perfil de traballo. Se o tempo de espera do bloqueo, as biometrías rexistradas ou o estado do perfil cambiaron recentemente, o uso da clave pode fallar mentres a clave en si está perfectamente ben.
O segundo é a invalidación permanente. Parte do material de claves queda invalidado pola política da plataforma cando se restablece o método de bloqueo ou cambia o rexistro biométrico, porque a vinculación que o protexía xa non se mantén. A clave non se pode reparar e reintentar non é un plan de recuperación; a identidade debe substituírse mediante o proceso de rexistro que a emitiu.
O terceiro é un fallo do provedor: o servizo de keystore non puido completar a operación agora mesmo. Esa é a clase que ás veces merece un reintento, e a única.
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
Observe que dous dos tres non son destrutivos e un non ten ningunha solución a nivel de dispositivo. Ningún se resolve borrando o teléfono, que é o paso que a xente dá primeiro porque o diálogo non lles ofrece nada máis sobre o que actuar.
Novo rexistro fronte a un borrado de datos
Estes dous parecen iguais desde fóra e non o son. O novo rexistro pide ao sistema emisor unha identidade nova — un certificado ou unha clave novos vinculados a este dispositivo — e retira a anterior. Un borrado de datos elimina o estado gardado da aplicación, o que pode quitar a referencia á clave sen quitar a clave, ou pode quitar a clave e deixalo sen autoridade para recreala.
A distinción importa porque as claves non exportables, por deseño, non son portables. Viven no keystore do dispositivo, respaldadas polo hardware ou o provedor dispoñible, e non son algo que unha copia de seguridade capture e unha restauración reinstale. Se a identidade do despregamento é unha clave non exportable, planifique o novo rexistro como recuperación e confirme de antemán que ten unha vía aprobada para obter ese rexistro: algunhas organizacións esixen acceso á rede privada para iso, que é exactamente o que proporcionaba a VPN avariada.
Así que a orde é: probe a vía de autenticación admitida, determine despois se a clave é permanentemente inválida e substitúa a identidade só se o é. Borrar o almacenamento vai ao final, despois de saber que se vai recrear, non primeiro porque sexa fácil.
Reintente só o que é reintentable
As versións antigas da plataforma agrupaban os erros de keystore nunha soa excepción, e por iso tantos clientes o reintentan todo. A partir da API 33 o tipo de excepción leva estrutura: un erro numérico, un indicador de fallo transitorio e unha política de reintento. Para un desenvolvedor de clientes, a política de reintento só ten sentido cando o indicador de transitoriedade é verdadeiro; unha invalidación permanente non ten calendario de reintentos, e martelala en bucle só esgota a batería e enche o rexistro.
Se diagnostica en lugar de escribir o cliente, a consecuencia práctica é a mesma. Os fallos idénticos en cada intento descartan un fallo puntual, pero non separan unha clave invalidada permanentemente dun provedor que leva un tempo non dispoñible: unha caída do provedor vese exactamente igual no décimo reintento que no primeiro. Sen os campos estruturados da API 33, trate a repetición como un motivo para buscar un segundo sinal — o código de erro se a súa compilación o expón, o estado do operador ou outra clave no mesmo dispositivo que si funciona — e non como proba de que a clave está morta.
Lea a cadea de causas, non a etiqueta
As aplicacións envolven a excepción orixinal, e a cadea amable da interface a miúdo oculta o único campo que decide a rama. Conserve a cadea de causas e a marca de tempo do intento: a excepción externa adoita nomear a operación, e a causa nomea o estado da clave.
Resista a inferencia de que dúas aplicacións que fallan demostran un teléfono defectuoso. Claves distintas poden estar respaldadas por provedores e niveis de seguridade distintos, e unha aplicación que aínda funciona pode que non execute a mesma operación en absoluto: unha sinatura, un descifrado e unha atestación de clave son peticións diferentes ao mesmo servizo. referencia de KeyStoreException describe os campos estruturados en niveis de API máis recentes e é o lugar onde comprobar que pode informar realmente a súa compilación.
O que respaldaría unha conclusión de hardware é máis estreito do que a maioría supón: a mesma operación, no mesmo provedor, fallando en claves independentes cun erro de nivel de provedor e non de nivel de clave. Iso é unha pregunta para o diagnóstico da plataforma, non para un fío dun foro de soporte sobre un lote de dispositivos.
Que rexistrar mentres decide
Rexistre a compilación de Android, a versión do cliente, o perfil seleccionado, a operación que fallou e se algo cambiou recentemente: unha actualización do sistema, un cambio de pantalla de bloqueo, unha pegada nova, un novo rexistro. Rexistre a secuencia como contexto e non como proba da causa; un cambio de bloqueo antes dun fallo de clave é unha correlación plausible, non unha demostración.
Logo actúe segundo a rama que establecese. Transitoria: conserve a identidade, use a vía de reintento admitida. Requírese autenticación: complete o fluxo de desbloqueo admitido e manteña a política de bloqueo que esixe o despregamento en lugar de desactivala para pasar un diálogo. Permanentemente inválida: substitúa e retire a identidade mediante o rexistro normal.
Termine demostrando o resultado nunha conexión autorizada nova, cara a un recurso real, coa validación do servidor aínda activada. Calquera cousa que só funcione con comprobacións de certificados relaxadas non arranxou o problema da clave: trasladouno á capa de rede, onde aparecerá máis tarde con síntomas peores.
- Tres ramas: require autenticación, permanentemente inválida, transitoria do provedor.
- Só a terceira se beneficia de reintentar, e só segundo a súa política de reintento.
- O novo rexistro restaura o acceso; un borrado de datos elimina a opción.
- Verifique cunha conexión nova e comprobacións de identidade de servidor normais.