Android IKEv2: el certificado de usuario y la CA hacen trabajos distintos

Una pantalla IKEv2 de Android que pide a la vez un certificado de usuario y uno de CA parece pedir lo mismo dos veces. No es así. IKEv2 autentica a ambos extremos en ambas direcciones dentro de un mismo intercambio, y el teléfono hace un papel distinto en cada dirección: debe probar quién es y decidir en qué puerta de enlace confía. El certificado de usuario responde a la primera pregunta, la CA de confianza a la segunda, y ninguno sustituye al otro.

Dos direcciones de autenticación en un solo intercambio

IKEv2 levanta un canal de control en dos fases. La primera negocia algoritmos y claves; la segunda, IKE_AUTH, lleva una carga AUTH de cada lado junto con su identidad. La carga es una firma o un MAC sobre el intercambio y se verifica contra algo en lo que el receptor ya confía.

La puerta de enlace se prueba con su propio certificado; el teléfono valida la cadena hasta una raíz que acepta y comprueba que la identidad del certificado coincide con la puerta que quería alcanzar. l teléfono se prueba con sus credenciales, y la puerta las verifica contra la CA que emitió el certificado de cliente.

Ese es todo el mecanismo. El certificado de usuario es una declaración del teléfono sobre sí mismo; el campo CA es una declaración sobre a quién creerá. Un perfil con uno pero no con el otro no completa la autenticación mutua y reintentar no lo cambia. Los fallos incluso se ven distintos: sin clave de usuario el teléfono no puede firmar, y sin anclaje de confianza no puede aceptar el certificado de la puerta.

Qué pide el generador de perfiles de Android

El generador de perfiles IKEv2 de Android expone cada método por separado, no como un único modo de certificado. La firma digital toma un certificado de usuario, una clave privada y una CA raíz del servidor; los demás toman usuario y contraseña, o una clave precompartida.

Lea esa firma con atención, porque describe el mecanismo anterior. No hay campo para la clave privada en el método de usuario y contraseña ni anclaje de confianza en PSK, porque prueban cosas distintas. Pegar una contraseña en un campo de certificado produce un perfil que falla en IKE_AUTH con un mensaje que no nombra ninguno de los dos.

El tipo de clave privada documentado para la firma digital es RSA. Un menú etiquetado IPsec o certificado no implica soporte de ECDSA, y un perfil construido sobre esa suposición falla en la API de la plataforma antes de que exista red.

Por qué no basta un certificado de usuario público

La carga AUTH es una firma sobre el intercambio hecha con la clave privada del cliente. El certificado público permite a la puerta comprobar una firma, pero no hace nada por el teléfono, que necesita la clave para generarla. Importar solo .crt y dejar la clave atrás es la forma más común de este fallo.

La infraestructura de claves de Android lo refleja: elegir una identidad de cliente pasa por KeyChain, que exige acceso a la clave privada correspondiente, no solo una entrada de certificado. Un paquete de inscripción o un flujo de gestión de dispositivos que instale el par junto es la vía normal; copiar el archivo a mano no suele serlo.

Así que los dos elementos no son un lote de certificados y su duplicado. Uno es un par de claves con el que la plataforma debe poder firmar; el otro, un anclaje de confianza con el que compara. Compruébelos como dos hechos separados: ¿puede firmar este perfil y sabe a quién confiar?

Los anclajes de confianza son de la aplicación, no del teléfono

Instalar una raíz en el almacén del usuario no hace que todas las aplicaciones confíen en ella: desde Android 7 una app debe optar por ello mediante su configuración de seguridad de red, y antes de esa versión las CA instaladas por el usuario se aceptaban mucho más ampliamente. La configuración de confianza varía y un cliente VPN que gestiona su propio material puede no mirar nunca el almacén. Por eso el mismo archivo de CA funciona en un cliente y parece ignorado en otro.

Hay dos modelos. Un perfil gestionado por el sistema usa la instalación de certificados del dispositivo o el alta de administrador y luego referencia la CA prevista. Un VPN gestionado por la aplicación guarda su propio material y su propia importación documentada, que puede estar separada de los ajustes de Android. Ahí también se repara una cadena rota.

Decida en qué modelo está antes de importar nada y confirme después la selección de confianza del perfil activo. Si las instrucciones del operador y el menú del cliente no coinciden, para esa instalación gana el comportamiento documentado del cliente, pero la CA debe seguir viniendo del operador por un canal verificable. El nombre de un archivo no prueba quién lo emitió.

Elija el modo y luego los archivos

El modo certificado necesita un par de claves de cliente, la CA emisora en el lado de la puerta, un anclaje de confianza para el certificado de la puerta y una expectativa de qué identidad debe llevar. Usuario y contraseña sustituyen el par por credenciales pero mantienen la confianza en la puerta. PSK sustituye ambos por un secreto compartido y cambia el modelo de confianza en vez de simplificarlo.

Elija lo que elija, mantenga la validación normal activada. Una opción de no verificar elimina la comprobación para la que existe el campo CA; no arregla un anclaje ausente. Lo mismo vale para aceptar cualquier certificado de servidor porque la conexión funcione sin él.

Después verifique en el lugar correcto: importe el material, conéctese una vez y confirme en los detalles que la identidad de la puerta es la esperada y que el perfil informa del método que pretendía. Una conexión correcta con el método equivocado es una configuración que aún no entiende y fallará cuando el operador endurezca una política.