Error de confianza de IKEv2 en Android: envíe el CA intermedio, no una raíz
El teléfono rechaza la puerta de enlace porque la cadena recibida termina antes. Decida: envíe el intermedio, corrija la identidad o cambie el tipo de clave.
El teléfono se niega a conectar e imprime No trusted RSA public key found for vpn.example.net, mientras que el mismo certificado de la puerta de enlace funciona desde un portátil en la misma red. La tentación es reemitir el certificado. Antes, averigüe cuál de las tres fallas tiene, porque solo una se refiere al contenido del certificado.
Tres fallas detrás de un mensaje
Android construye una cadena desde el certificado de la puerta de enlace hasta el CA elegido en el perfil VPN y luego compara el nombre del servidor con el perfil. El aviso informa el resultado, no la etapa. Una falla de confianza significa que la cadena no pudo completarse con los certificados entregados en el intercambio; una falla de identidad, que la cadena es válida pero el nombre no coincide; una falla de algoritmo, que el dispositivo o el perfil no acepta el tipo de clave o la firma.
| 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 con pruebas en lugar de probar reparaciones en orden. Un intento en el nivel 2 del registro del demonio le dice en qué fila está y cuesta menos que reemitir un certificado que nunca estuvo mal.
Decida primero: ¿llegó la cadena completa?
strongSwan envía el certificado configurado para esa conexión, y los certificados intermedios son credenciales aparte. Deben cargarse como certificados CA antes de que el demonio pueda ponerlos en una carga, así que un diseño donde el certificado del servidor está firmado por un intermedio, la raíz es el ancla de confianza y el intermedio solo vive en el directorio de compilación del CA produce exactamente esta falla: solo la hoja en el cable y la cadena que termina pronto en el teléfono.
Compruebe qué tiene el demonio con swanctl --list-certs en un despliegue swanctl, o ipsec listcerts con el starter antiguo. El intermedio debe aparecer como certificado CA con la raíz por encima. Si falta, ninguna opción del cliente ayudará; si está, pase a la siguiente pregunta.
Luego compruebe si se enviaría. La referencia de swanctl.conf documenta send_cert, cuyo valor por defecto ifasked envía certificados solo cuando el par lo ha pedido, mientras que always envía siempre. El equivalente antiguo es leftsendcert=always en ipsec.conf. Ese ajuste controla el envío, no la disponibilidad, así que no compensa un intermedio que el demonio nunca cargó.
Si la cadena es corta, cargue el intermedio donde busca el demonio
Ponga el intermedio en el directorio CA, no junto a la hoja: /etc/ipsec.d/cacerts para un diseño con ipsec.conf, /etc/swanctl/x509ca para swanctl, o la ruta que sustituye su paquete. Recargue la configuración y vuelva a listar los certificados. Algunas versiones también envían un paquete que contiene la cadena dentro del archivo de la hoja, pero el directorio CA es la disposición portátil entre versiones y paquetes.
Verifique también desde el lado del cliente. El teléfono solo ve lo que llevó el intercambio, así que el registro del demonio en el nivel 2 debe mostrar el intermedio entre los certificados enviados. Si el registro lo muestra y el teléfono sigue fallando, está en otra fila de la tabla y ajustar archivos CA no cambiará el resultado.
Si la cadena está completa, deje de editar certificados
Una falla de identidad es un desacuerdo entre el nombre del perfil VPN y el nombre del certificado. Android compara la identidad del servidor que configuró con el certificado que validó, así que un perfil que apunta a una dirección mientras el certificado nombra un host, o un perfil que nombra un host que el certificado no cubre, falla tras una validación correcta de la cadena. Corrija el lado equivocado y mantenga perfil y certificado alineados cuando uno cambie.
Una falla de algoritmo aparece con una cadena válida y un nombre coincidente. Las versiones de Android difieren en qué tipos de clave y esquemas de firma aceptan, y el propio tipo de perfil limita las opciones. Si la puerta de enlace usa una combinación antigua o inusual, compárela con lo que admite el dispositivo antes de suponer que el certificado está dañado. El registro mostrará que el saludo avanza más que en el caso de confianza, la señal de que la cadena ya no es el problema.
No instale el intermedio como raíz de usuario en el teléfono
Instalar el intermedio que falta como certificado de usuario en el teléfono hace desaparecer el aviso y cambia el modelo de confianza del teléfono para cada aplicación que acepta raíces instaladas por el usuario. También oculta un fallo de entrega que golpeará al siguiente cliente y deja a la puerta de enlace enviando una cadena incompleta a cada dispositivo futuro. La reparación duradera está en el servidor, una vez, para todos los clientes.
Mantenga las tres decisiones separadas en el registro de cambios: qué certificados se transmitieron, qué identidad se comparó y qué algoritmo se negoció. Una puerta de enlace que siempre envía su cadena completa, un perfil que nombra correctamente el certificado y un tipo de clave que la flota admite son tres hechos pequeños, y son toda esta falla.