Configuración del certificado IKEv2 en iPhone: inscripción manual o gestionada

Elegir RSA porque la herramienta de certificados de la puerta de enlace lo usa por defecto es una decisión tomada antes de la pregunta que importa: ¿cómo se inscribirán estos iPhone? Una conexión escrita por el usuario y un perfil de configuración entregado por la gestión exponen ajustes distintos, y algunas opciones de certificado solo existen en una de esas vías. Acierte el orden y el plan del certificado se vuelve corto; equivóquese y emitirá una credencial que el teléfono no usará. Trate los pasos siguientes como una secuencia, porque cada uno estrecha las opciones disponibles para el siguiente.

Paso uno: elija la vía de inscripción

La configuración manual significa que el usuario introduce la dirección del servidor, elige el método de autenticación y aporta cualquier credencial que permita la interfaz. La inscripción gestionada significa que un perfil lleva la dirección, los identificadores y una referencia a una carga de credenciales. La vía gestionada puede expresar combinaciones que la pantalla manual no puede, por eso la decisión del certificado debe llegar después de esta elección, no antes.

Ambas vías pueden autenticar un teléfono. Difieren en lo que se puede configurar y en quién posee la identidad, así que elija una a conciencia en lugar de mezclar un perfil gestionado con la entrada manual de credenciales.

Paso dos: elija algoritmos para la vía que escogió

Para los iPhone configurados manualmente, las notas de interoperabilidad con iOS de strongSwan recomiendan un certificado de servidor RSA, porque el cliente manual puede no aceptar un certificado de servidor ECDSA; esas mismas notas tratan macOS por separado. Léalo como una guía para el conjunto de clientes admitidos, no como una ley permanente sobre los dispositivos Apple. Un perfil gestionado tiene más margen: puede seleccionar un tipo de certificado de forma explícita, incluida una identidad de cliente ECDSA, cuando la carga y la puerta de enlace lo admiten ambas.

Valide las versiones de iOS que realmente admite antes de desplegar nada. Un teléfono de laboratorio con la versión más reciente no describe un parque que incluye dispositivos más antiguos, y un algoritmo que funciona en el laboratorio puede fallar igualmente en el teléfono más antiguo del campo. Saque el rango de versiones de la gestión de dispositivos y no de la memoria. Si el parque abarca varias versiones, pruebe primero la más antigua, porque es donde la interfaz manual es más restrictiva.

Paso tres: lea los campos del perfil como cosas separadas

Varias claves de nombre parecido describen objetos distintos. La dirección remota es el host al que llama el teléfono. El identificador remoto es la identidad IKE que espera que presente la puerta de enlace. La referencia al certificado de la carga apunta a una credencial de cliente, y el campo de tipo de certificado selecciona el tipo usado para la autenticación de máquina IKEv2. Ninguno de ellos es el algoritmo de firma de la CA, aunque las palabras se solapen.

La referencia de carga IKEv2 de Apple enumera RSA como tipo de certificado predeterminado con variantes ECDSA explícitas, y vincula la clave de nombre del emisor con ajustes de autenticación concretos. Lea esas relaciones en la referencia del método que eligió en lugar de copiar una clave de un despliegue que funciona.

Paso cuatro: haga que la identidad de la puerta de enlace coincida con su certificado

Use un nombre de puerta de enlace explícito, por ejemplo vpn.example.com y ponga un nombre alternativo de sujeto coincidente en el certificado del servidor. La guía de strongSwan para Apple también espera el uso extendido de clave para la autenticación del servidor. Elegir RSA o ECDSA no cambia nada de eso: un algoritmo no puede reparar una discrepancia de nombre, un EKU ausente ni una cadena incompleta.

Distribuir el ancla de confianza es una tarea aparte de afirmar la identidad. El teléfono necesita una cadena de certificados que pueda validar, y debe configurarse para esperar el nombre que realmente puso en el certificado.

Que otra plataforma se conecte con éxito es evidencia sobre las reglas de validación de esa plataforma, no permiso para relajar las del teléfono. Mantenga las comprobaciones idénticas entre clientes salvo que tenga un motivo documentado para diferenciarlas.

Paso cinco: separe la identidad del cliente de la confianza en la CA

Un certificado de cliente y su clave privada no son el mismo objeto que el certificado de CA en el que confía el teléfono. Empaquetar un certificado de CA dentro de una identidad PKCS#12 no lo instala automáticamente como ancla de confianza en todos los dispositivos admitidos, así que trate la distribución de confianza como un paso propio con su propia verificación.

Si el diseño usa EAP basado en contraseña, el teléfono necesita la autenticación de cuenta prevista más la validación del servidor. Esa vía no justifica enviar una clave privada de cliente compartida a todo el parque, que es un diseño distinto con un modo de fallo mucho peor.

Termine el plan pensando en la renovación y la revocación: quién reemite la credencial del cliente, cómo se actualiza el perfil y cómo se corta un teléfono perdido. Registre la versión del perfil y las versiones de dispositivo con las que validó, porque ese registro es lo que convierte la próxima rotación de certificados en un cambio rutinario.