En macOS, la elección de ECDSA en un ajuste de cliente IKEv2 responde a una pregunta estrecha: qué certificado demuestra la identidad del Mac. No describe el certificado de la puerta de enlace, la firma que emitió el certificado del cliente ni la propuesta de cifrado del túnel. Tratar esos cuatro roles como una sola cuestión de compatibilidad es la forma en que una configuración local correcta acaba culpada de un desajuste del lado del servidor. La decisión es pequeña, pero las pruebas que se usan para tomarla deben ser precisas.

El campo nombra un certificado: la identidad local

La API Network Extension de Apple expone un tipo de certificado para la credencial del cliente, incluido NEVPNIKEv2CertificateType.ECDSA256, documentado como el tipo de certificado ECDSA p-256. La propiedad se aplica al certificado suministrado mediante identityReference o identityData.

Eso significa que la decisión trata del certificado que presenta el Mac, más la clave privada que lo acompaña. Elige el tipo que coincida con la clave pública de ese certificado hoja y entrega la identidad mediante el mecanismo admitido. Si el Mac no tiene una clave privada utilizable para la identidad, la elección del tipo no puede salvar la conexión.

Los perfiles gestionados toman la misma decisión mediante CertificateType de la carga de IKEv2, junto con una referencia de certificado como PayloadCertificateUUID. Esos campos tienen requisitos previos y un esquema para la versión del sistema operativo de destino; un valor de tipo desnudo copiado en un perfil no es instalable, y una ventana de ajustes puede no exponer todas las opciones de la API. Comprueba los requisitos previos de la carga para esa versión antes del despliegue.

Decide por rol, no por la etiqueta del certificado

Lee el campo que estás a punto de cambiar y pregunta a qué certificado apunta. Las etiquetas de un visor de certificados mezclan el sujeto, el emisor y el algoritmo de firma, y solo una de ellas pertenece a la elección de la identidad del cliente.

What you inspectedWhat it controlsDoes it choose the Mac certificate type?
Client leaf public keyThe identity the Mac presentsYes, this is the field's subject
Issuer signature algorithmHow the client certificate was signedNo
Gateway certificateWhat the Mac validates as the peerNo, check it separately
IKE and ESP proposalsAlgorithms for the tunnelNo, separate proposal settings

Si el visor de certificados muestra una firma ECDSA de la CA, eso describe la clave de firma del emisor. La clave propia del cliente puede seguir siendo RSA, y el campo de tipo debe seguir la clave del cliente, no la línea de firma. Esta única confusión explica muchos informes de "ECDSA está configurado pero la conexión falla". Compara el tipo de clave de la hoja con el tipo seleccionado en el perfil antes de cambiar nada.

La decisión se simplifica una vez identificada la hoja: ECDSA256 para una clave de cliente p-256, otro tipo admitido para una clave distinta. Si el certificado del cliente y su clave no coinciden, corrige ese par antes de cambiar el perfil de VPN.

El certificado de la puerta de enlace es una decisión aparte

La puerta de enlace presenta su propio certificado y el Mac lo valida contra un ancla de confianza y un nombre esperado. Que ese certificado use ECDSA, RSA u otro tipo de clave es una propiedad del servidor, no del ajuste de identidad del cliente.

La compatibilidad local con un certificado de cliente ECDSA no demuestra que todos los certificados de puerta de enlace, curvas o configuraciones de autenticación del servidor vayan a interoperar. Comprueba la identidad del servidor, su cadena y su método de autenticación IKE como entradas separadas, y prueba con el perfil que realmente se desplegará.

Si el certificado de la puerta de enlace es el problema, el síntoma suele aparecer durante la validación del par, no en la selección de identidad. Lee la etapa de fallo antes de cambiar el tipo de cliente, porque un fallo de confianza y un desajuste de clave del cliente no comparten solución.

La firma del emisor y el grupo de acuerdo de claves no son el tipo del cliente

X.509 mantiene la clave pública del sujeto y la firma del emisor en campos distintos. La información de clave pública del sujeto describe la clave del certificado; el algoritmo de firma describe la clave de la CA y la operación de firma. Solo la primera coincide con el ajuste de tipo de certificado.

Las propuestas de IKE y Child SA son otro eje. Un tipo de certificado ECDSA no es una elección de cifrado ESP, y cambiar el grupo de acuerdo de claves no selecciona un tipo de certificado. Un perfil puede tener propuestas válidas y el tipo de identidad equivocado, o el tipo de identidad correcto y una propuesta que el par rechaza.

Mantén las tres líneas separadas en el registro de cambios: certificado y clave de identidad, entradas de confianza de la puerta de enlace y algoritmos de las propuestas. Combinarlas en una sola nota de "ajustes cripto" hace que el siguiente fallo sea imposible de atribuir.

Verifica la decisión con los campos que configuraste

Comprueba la identidad a la que el perfil hace referencia realmente, y luego confirma que el certificado de esa referencia tiene la clave pública esperada y una clave privada utilizable. El tipo mostrado en la interfaz, el certificado referenciado y la clave del dispositivo tienen que coincidir.

A continuación confirma las entradas de la puerta de enlace: el nombre del servidor esperado, el ancla de confianza y el método de autenticación IKE. Por último, conéctate y lee dónde se detiene el handshake. Un fallo antes del intercambio de identidad apunta fuera de este ajuste; un fallo en la validación del par apunta al lado de la puerta de enlace.

Anota el tipo elegido, la referencia de identidad y el sujeto del certificado de la puerta de enlace en las notas de despliegue. La próxima actualización del perfil puede cambiar cualquiera de ellos, y tres valores nombrados se comparan más rápido que una captura de pantalla de un panel de ajustes.

Artículos relacionados