Erro de confianza de IKEv2 en Android: envía o CA intermedio, non unha raíz
O teléfono rexeita a pasarela porque a cadea recibida remata cedo. Decide: envía o intermedio, corrixe a identidade ou cambia o tipo de chave.
O teléfono négase a conectar e imprime No trusted RSA public key found for vpn.example.net, mentres que o mesmo certificado da pasarela funciona desde un portátil na mesma rede. A tentación é reemitir o certificado. Antes, determina cal das tres fallas tes, porque só unha se refire ao contido do certificado.
Tres fallas detrás dunha mensaxe
Android constrúe unha cadea desde o certificado da pasarela ata o CA elixido no perfil VPN e logo compara o nome do servidor co perfil. O aviso informa o resultado, non a etapa. Unha falla de confianza significa que a cadea non se puido completar cos certificados entregados no intercambio; unha falla de identidade, que a cadea é válida pero o nome non coincide; unha falla de algoritmo, que o dispositivo ou o perfil non acepta o tipo de chave ou a sinatura.
| 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 |
Decide con probas en lugar de probar reparacións en orde. Un intento no nivel 2 do rexistro do demonio diche en que fila estás e custa menos que reemitir un certificado que nunca estivo mal.
Decide primeiro: chegou a cadea completa?
strongSwan envía o certificado configurado para esa conexión, e os certificados intermedios son credenciais aparte. Deben cargarse como certificados CA antes de que o demonio os poida poñer nunha carga, así que un deseño onde o certificado do servidor está asinado por un intermedio, a raíz é a áncora de confianza e o intermedio só vive no directorio de compilación do CA produce exactamente esta falla: só a folla no fío e a cadea que remata cedo no teléfono.
Comproba que ten o demonio con swanctl --list-certs nun despregamento swanctl, ou ipsec listcerts co starter antigo. O intermedio debe aparecer como certificado CA coa raíz por riba. Se falta, ningunha opción do cliente axudará; se está, pasa á seguinte pregunta.
Logo comproba se se enviaría. A referencia de swanctl.conf documenta send_cert, cuxo valor por defecto ifasked envía certificados só cando o par o pediu, mentres que always envía sempre. O equivalente antigo é leftsendcert=always en ipsec.conf. Ese axuste controla o envío, non a dispoñibilidade, así que non compensa un intermedio que o demonio nunca cargou.
Se a cadea é curta, carga o intermedio onde busca o demonio
Pon o intermedio no directorio CA, non xunto á folla: /etc/ipsec.d/cacerts para un deseño con ipsec.conf, /etc/swanctl/x509ca para swanctl, ou a ruta que substitúe o teu paquete. Recarga a configuración e lista os certificados de novo. Algunhas versións tamén envían un paquete que contén a cadea dentro do ficheiro da folla, pero o directorio CA é a disposición portátil entre versións e paquetes.
Verifica tamén desde o lado do cliente. O teléfono só ve o que levou o intercambio, así que o rexistro do demonio no nivel 2 debe amosar o intermedio entre os certificados enviados. Se o rexistro o amosa e o teléfono segue fallando, estás noutra fila da táboa e axustar ficheiros CA non cambiará o resultado.
Se a cadea está completa, deixa de editar certificados
Unha falla de identidade é un desacordo entre o nome do perfil VPN e o nome do certificado. Android compara a identidade do servidor que configurou co certificado que validou, así que un perfil que apunta a un enderezo mentres o certificado nomea un host, ou un perfil que nomea un host que o certificado non cobre, falla tras unha validación correcta da cadea. Corrixe o lado equivocado e mantén perfil e certificado aliñados.
Unha falla de algoritmo aparece cunha cadea válida e un nome coincidente. As versións de Android difiren en que tipos de chave e esquemas de sinatura aceptan, e o propio tipo de perfil limita as opcións. Se a pasarela usa unha combinación antiga ou incomún, compáraa co que admite o dispositivo antes de supoñer que o certificado está danado. O rexistro amosará que o aperto de mans avanza máis que no caso de confianza, o sinal de que a cadea xa non é o problema.
Non instales o intermedio como raíz de usuario no teléfono
Instalar o intermedio que falta como certificado de usuario no teléfono fai desaparecer o aviso e cambia o modelo de confianza do teléfono para cada aplicación que acepta raíces instaladas polo usuario. Tamén oculta un fallo de entrega que golpeará o seguinte cliente e deixa a pasarela enviando unha cadea incompleta a cada dispositivo futuro. A reparación duradeira está no servidor, unha vez, para todos os clientes.
Mantén as tres decisións separadas no rexistro de cambios: que certificados se transmitiron, que identidade se comparou e que algoritmo se negociou. Unha pasarela que sempre envía a súa cadea completa, un perfil que nomea correctamente o certificado e un tipo de chave que a frota admite son tres feitos pequenos, e son toda esta falla.