Android IKEv2: o certificado de usuário e a CA fazem trabalhos diferentes
Um campo prova quem é o telefone, o outro decide em qual gateway confiar. O perfil IKEv2 do Android mantém os dois separados.
Uma tela IKEv2 do Android que pede ao mesmo tempo um certificado de usuário e um certificado de CA parece pedir a mesma coisa duas vezes. Não é assim. O IKEv2 autentica os dois lados nas duas direções dentro de uma única troca, e o telefone tem um papel diferente em cada direção: provar quem é e decidir em qual gateway acredita. O certificado de usuário responde à primeira pergunta, a CA confiável à segunda, e nenhum substitui o outro.
Duas direções de autenticação em uma só troca
O IKEv2 constrói um canal de controle em duas fases. A primeira negocia algoritmos e chaves; a segunda, IKE_AUTH, carrega um conteúdo AUTH de cada lado junto com sua identidade. Esse conteúdo é uma assinatura ou MAC sobre a troca e é verificado contra algo em que o receptor já confia.
O gateway prova a própria identidade com seu certificado, e o telefone valida a cadeia até uma raiz que aceita e verifica se a identidade do certificado corresponde ao gateway que pretendia alcançar; o telefone prova a própria identidade com suas credenciais, e o gateway as verifica contra a CA que emitiu o certificado de cliente.
Esse é todo o mecanismo por trás dos dois campos. O certificado de usuário é uma declaração do telefone sobre si mesmo; o campo de CA é uma declaração sobre em quem ele vai acreditar. Um perfil com um sem o outro não conclui a autenticação mútua, e repetir não muda isso. Até as falhas parecem diferentes: sem chave de usuário o telefone não assina, e sem âncora de confiança não aceita o certificado do gateway.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
O que o criador de perfis do Android exige
O criador de perfis IKEv2 do Android expõe cada método de autenticação separadamente, não como um único modo de certificado. O método de assinatura digital usa um certificado de usuário, uma chave privada e uma CA raiz do servidor; os outros usam nome de usuário e senha, ou uma chave pré-compartilhada.
Leia essa assinatura com atenção, porque ela descreve o mecanismo acima. Não há campo para a chave privada no método de usuário e senha, nem âncora de confiança no PSK, porque esses métodos provam coisas diferentes. Uma senha colada em um campo de certificado gera um perfil que falha no IKE_AUTH com uma mensagem que não nomeia nenhum dos dois.
O tipo de chave privada documentado para a assinatura digital é RSA. Um menu rotulado IPsec ou certificado não implica suporte a ECDSA, e um perfil construído sobre essa suposição falha na API da plataforma antes de a rede existir.
Por que um certificado público não basta
O conteúdo AUTH é uma assinatura sobre a troca feita com a chave privada do cliente. O certificado público permite ao gateway conferir uma assinatura, mas não faz nada pelo telefone, que precisa da chave para produzi-la. Importar apenas .crt e deixar a chave para trás é a forma mais comum desse erro.
A infraestrutura de chaves do Android reflete isso: escolher uma identidade de cliente passa pelo KeyChain, que exige acesso à chave privada correspondente, não apenas um registro de certificado. Um pacote de inscrição ou fluxo de gestão de dispositivos que instale o par junto é o caminho normal; copiar o arquivo à mão geralmente não é.
Assim, os dois itens do perfil não são um lote de certificados e sua duplicata. Um é um par de chaves com o qual a plataforma precisa assinar, o outro é uma âncora de confiança com a qual compara. Verifique os dois como fatos separados: este perfil consegue assinar e sabe em quem confiar?
Âncoras de confiança pertencem ao aplicativo, não ao telefone
Instalar uma raiz no armazenamento do usuário não faz todo aplicativo Android confiar nela: desde o Android 7 um aplicativo precisa optar por isso na configuração de segurança de rede, e antes dessa versão as CAs instaladas pelo usuário eram aceitas muito mais amplamente. A configuração de confiança varia, e um cliente VPN que administra o próprio material de confiança pode nunca olhar o armazenamento. Por isso o mesmo arquivo de CA funciona em um cliente e parece ignorado em outro.
Daí vêm dois modelos. Um perfil gerenciado pelo sistema usa a instalação de certificados do dispositivo ou a inscrição do administrador e depois referencia a CA pretendida. Um VPN gerenciado pelo aplicativo mantém seu próprio material de confiança e sua própria importação documentada, que pode ser totalmente separada das configurações do Android. É também onde se repara uma cadeia quebrada.
Decida em qual modelo você está antes de importar qualquer coisa e depois confirme a seleção de confiança do perfil ativo. Se as instruções do operador e o menu do cliente divergirem, para essa instalação vence o comportamento documentado do cliente, mas a CA ainda deve vir do operador por um canal verificável. O nome do arquivo não prova quem o emitiu.
Escolha o modo e depois os arquivos
O modo certificado exige um par de chaves do cliente, a CA emissora no lado do gateway, uma âncora de confiança para o certificado do gateway e uma expectativa de qual identidade ele deve carregar. Nome de usuário e senha substituem o par por credenciais mas mantêm a exigência de confiança no gateway. PSK substitui os dois por um segredo compartilhado e muda o modelo de confiança em vez de simplificá-lo.
Escolha o que escolher, mantenha a validação normal ativa. Uma opção sem verificação remove a checagem para a qual o campo de CA existe; ela não corrige uma âncora ausente. O mesmo vale para aceitar qualquer certificado de servidor porque a conexão funciona sem ele.
Depois verifique no lugar certo: importe o material, conecte uma vez e confirme nos detalhes que a identidade do gateway é a esperada e que o perfil informa o método pretendido. Uma conexão bem-sucedida com o método errado é uma configuração que você ainda não entende, e falhará quando o operador endurecer uma política.