Erro de keystore na VPN Android: reinscrever, desbloquear ou tentar novamente?

O perfil continua listado, o certificado ainda aparece como instalado e o botão de ligação falha com uma mensagem que diz apenas Erro de keystore e nada mais. Antes de limpar o armazenamento da aplicação ou entregar o telefone, determine que operação de chave falhou. Três resultados produzem essa mesma caixa de diálogo e respondem a três ações diferentes — apenas uma delas é destrutiva. A comparação vale dez minutos, porque o ramo errado custa-lhe a identidade que estava a tentar manter.

Três falhas por trás de uma caixa de diálogo

A primeira é a autenticação. A chave existe e é válida, mas usá-la exige que o utilizador prove presença — um desbloqueio do dispositivo, uma biometria ou um desafio de perfil de trabalho. Se o tempo limite de bloqueio, as biometrias inscritas ou o estado do perfil mudaram recentemente, a utilização da chave pode falhar embora a chave em si esteja perfeitamente bem.

A segunda é a invalidação permanente. Algum material de chave é invalidado pela política da plataforma quando o método de bloqueio é reposto ou a inscrição biométrica muda, porque a ligação que o protegia já não se mantém. A chave não pode ser reparada e tentar novamente não é um plano de recuperação; a identidade tem de ser substituída através do processo de inscrição que a emitiu.

A terceira é uma falha do fornecedor: o serviço de keystore não conseguiu concluir a operação neste momento. É a classe que por vezes vale a pena tentar de novo, e a única.

Repare que duas das três são não destrutivas e uma não tem solução alguma ao nível do dispositivo. Nenhuma delas se resolve apagando o telefone, que é o passo que as pessoas dão primeiro porque a caixa de diálogo não lhes dá mais nada em que agir.

Nova inscrição versus limpeza de dados

Estas duas parecem semelhantes vistas de fora e não são. A nova inscrição pede ao sistema emissor uma nova identidade — um certificado ou chave novos ligados a este dispositivo — e retira a antiga. Uma limpeza de dados apaga o estado guardado da aplicação, o que pode remover a referência à chave sem remover a chave, ou pode remover a chave e deixá-lo sem autoridade para a recriar.

A distinção importa porque as chaves não exportáveis não são, por conceção, portáveis. Vivem no keystore do dispositivo, suportado pelo hardware ou fornecedor que estiver disponível, e não são algo que uma cópia de segurança capture e um restauro reponha. Se a identidade da implementação for uma chave não exportável, conte com a nova inscrição como recuperação e confirme antecipadamente que tem uma via aprovada para obter essa inscrição — algumas organizações exigem acesso à rede privada para isso, que é exatamente o que a VPN avariada estava a fornecer.

Portanto a ordem é: experimentar o caminho de autenticação suportado, depois determinar se a chave está permanentemente inválida e só substituir a identidade se estiver. Limpar o armazenamento fica em último lugar, depois de saber o que será recriado, e não primeiro por ser fácil.

Tentar novamente apenas o que é repetível

Versões mais antigas da plataforma reduziam os erros de keystore a uma única exceção, e é por isso que tantos clientes tentam tudo de novo. A partir da API 33, o tipo de exceção transporta estrutura: um erro numérico, um indicador de falha transitória e uma política de novas tentativas. Para quem desenvolve o cliente, a política de novas tentativas só tem sentido quando o indicador de transitório é verdadeiro; uma invalidação permanente não tem calendário de novas tentativas, e martelá-la em ciclo apenas gasta a bateria e enche o registo.

Se está a diagnosticar em vez de escrever o cliente, a consequência prática é a mesma. Falhas idênticas em todas as tentativas excluem uma anomalia pontual, mas não separam uma chave permanentemente invalidada de um fornecedor que está indisponível há algum tempo — uma indisponibilidade do fornecedor parece exatamente igual na décima tentativa e na primeira. Sem os campos estruturados da API 33, trate a repetição como motivo para procurar um segundo sinal — o código de erro, se a sua compilação expuser um, o estado do operador, ou uma chave diferente no mesmo dispositivo a funcionar — e não como prova de que a chave está morta.

Leia a cadeia de causas, não o rótulo

As aplicações envolvem a exceção original, e a cadeia amigável na interface esconde frequentemente o único campo que decide o ramo. Preserve a cadeia de causas e o carimbo temporal da tentativa: a exceção exterior nomeia habitualmente a operação, e a causa nomeia a condição da chave.

Resista à inferência de que duas aplicações a falhar provam um telefone defeituoso. Chaves diferentes podem ser suportadas por fornecedores e níveis de segurança diferentes, e uma aplicação que ainda funciona pode não exercer a mesma operação de todo — uma assinatura, uma desencriptação e uma atestação de chave são pedidos diferentes ao mesmo serviço. A referência da KeyStoreException descreve os campos estruturados nos níveis de API mais recentes e é o local onde verificar o que a sua compilação consegue realmente reportar.

O que sustentaria uma conclusão de hardware é mais estreito do que a maioria das pessoas assume: a mesma operação, no mesmo fornecedor, a falhar em chaves independentes com um erro ao nível do fornecedor e não ao nível da chave. Essa é uma questão para os diagnósticos da plataforma, não para um tópico de fórum de suporte sobre um lote de dispositivos.

O que registar enquanto decide

Registe a compilação do Android, a versão do cliente, o perfil selecionado, a operação que falhou e se algo mudou recentemente — uma atualização do sistema, uma alteração do ecrã de bloqueio, uma nova impressão digital, uma nova inscrição. Anote a sequência como contexto e não como prova da causa; uma alteração de bloqueio antes de uma falha de chave é uma correlação plausível, não uma demonstração.

Depois atue conforme o ramo que estabeleceu. Transitória: mantenha a identidade, use o caminho de novas tentativas suportado. Autenticação necessária: conclua o fluxo de desbloqueio suportado e mantenha a política de bloqueio exigida pela implementação em vez de a desativar para ultrapassar uma caixa de diálogo. Permanentemente inválida: substitua e retire a identidade através da inscrição normal.

Termine provando o resultado numa ligação autorizada nova, a um recurso real, com a validação do servidor ainda ativa. Tudo o que só funciona com as verificações de certificado relaxadas não corrigiu o problema da chave — deslocou-o para a camada de rede, onde virá ao de cima mais tarde com sintomas piores.

• Três ramos: precisa de autenticação, permanentemente inválida, transitória do fornecedor.
• Só o terceiro beneficia de novas tentativas, e apenas segundo a sua política de novas tentativas.
• A nova inscrição de substituição restaura o acesso; uma limpeza de dados remove a opção.
• Verifique com uma ligação nova e verificações normais da identidade do servidor.