Erro de confiança Android IKEv2: envie a AC intermédia, não uma raiz
O telemóvel rejeita o gateway porque a cadeia recebida termina cedo. Decida: enviar a intermédia, corrigir a identidade ou mudar o tipo de chave.
O telemóvel recusa ligar-se e imprime No trusted RSA public key found for vpn.example.net, enquanto o mesmo certificado do gateway funciona num portátil na mesma rede. O passo tentador é reemitir o certificado. Antes disso, determine qual das três falhas tem, porque só uma delas diz respeito ao conteúdo do certificado. A mensagem abrange uma cadeia incompleta, uma incompatibilidade de identidade e uma chave ou assinatura não suportada, e cada uma tem uma reparação diferente.
Três falhas por trás de uma mensagem
O Android constrói uma cadeia desde o certificado do gateway até à AC selecionada no perfil VPN e depois compara o nome do servidor com o perfil. A notificação comunica o resultado, não a fase. Uma falha de confiança significa que a cadeia não pôde ser completada com os certificados entregues na troca; uma falha de identidade significa que a cadeia foi validada mas o nome não coincidia; uma falha de algoritmo significa que o dispositivo ou o perfil não aceita o tipo de chave ou a assinatura.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Decida com evidências em vez de tentar reparações por ordem. Uma tentativa com nível de registo 2 contra o daemon diz-lhe em que linha está, e custa menos do que reemitir um certificado que nunca estava errado.
Decida primeiro: chegou a cadeia completa?
O strongSwan envia o certificado configurado para essa ligação, e as intermédias são credenciais separadas. Têm de ser carregadas como certificados de AC antes de o daemon as poder colocar numa carga útil, pelo que uma disposição em que o certificado do servidor é assinado por uma intermédia, a raiz é a âncora de confiança e a intermédia existe apenas na pasta de compilação da AC produz exatamente esta falha: só a folha no fio, cadeia a terminar cedo no telemóvel.
Verifique o que o daemon tem com swanctl --list-certs numa instalação swanctl, ou ipsec listcerts com o starter mais antigo. A intermédia deve aparecer como certificado de AC com a raiz por cima. Se faltar, nenhuma opção do cliente ajuda; se estiver presente, passe à pergunta seguinte.
Depois verifique se seria enviada. A referência do swanctl.conf documenta send_cert, cujo padrão ifasked só envia certificados quando o par pediu; always envia sempre. O equivalente legado é leftsendcert=always em ipsec.conf. Essa definição controla o envio, não a disponibilidade, pelo que não pode compensar uma intermédia que o daemon nunca carregou.
Se a cadeia for curta, carregue a intermédia onde o daemon procura
Coloque a intermédia na pasta da AC e não ao lado da folha: /etc/ipsec.d/cacerts para uma configuração ipsec.conf, /etc/swanctl/x509ca para swanctl, ou o caminho que o seu pacote substitui. Recarregue a configuração e liste os certificados novamente. Algumas versões também enviam um pacote que contém a cadeia dentro do ficheiro da folha, mas a pasta da AC é a disposição portátil entre versões e pacotes.
Verifique também do lado do cliente. O telemóvel só vê o que a troca transportou, pelo que o registo do daemon no nível 2 deve mostrar a intermédia nos certificados transmitidos. Se o registo a mostrar e o telemóvel continuar a falhar, está noutra linha da tabela, e continuar a ajustar ficheiros de AC não mudará o resultado.
Se a cadeia estiver completa, pare de editar certificados
Uma falha de identidade é uma incompatibilidade entre o nome no perfil VPN e o nome no certificado. O Android compara a identidade do servidor que configurou com o certificado que validou, pelo que um perfil que aponta para um endereço enquanto o certificado indica um nome de anfitrião, ou um perfil que indica um nome de anfitrião que o certificado não cobre, falha após uma validação de cadeia bem-sucedida. Corrija o lado errado e mantenha o perfil e o certificado alinhados quando qualquer um mudar.
Uma falha de algoritmo aparece com uma cadeia válida e um nome correspondente. As versões do Android diferem nos tipos de chave e esquemas de assinatura que aceitam, e o próprio tipo de perfil restringe as opções. Se o gateway usar uma combinação mais antiga ou invulgar, compare-a com o que o dispositivo suporta antes de assumir que o certificado está corrompido. O registo do daemon mostrará o handshake a avançar mais do que no caso de confiança, e esse é o sinal de que a cadeia já não é o problema.
Não instale a intermédia como raiz de utilizador no telemóvel
Instalar a intermédia em falta como certificado de utilizador no telemóvel faz desaparecer o aviso e altera o modelo de confiança do telemóvel para todas as aplicações que aceitam raízes instaladas pelo utilizador. Também esconde um erro de entrega que atingirá o próximo cliente, e deixa o gateway a enviar uma cadeia incompleta a todos os dispositivos futuros. A reparação duradoura é no servidor, uma vez, para todos os clientes.
Mantenha as três decisões separadas no registo de alterações: que certificados foram transmitidos, que identidade foi comparada e que algoritmo foi negociado. Um gateway que envia sempre a cadeia completa, um perfil que nomeia corretamente o certificado e um tipo de chave que a frota suporta são três pequenos factos, e são a totalidade desta falha.