Certificado IKEv2 y SAN: por qué falla la comprobación de identidad

La cadena de su certificado llega a una CA de confianza, las fechas son correctas y el par sigue negándose a completar la fase 1 con un error de identidad. El alcance y una firma válida son solo la mitad de lo que comprueba un cliente IKEv2. La otra mitad es si la identidad que espera aparece en el certificado en el campo correcto, y esa expectativa la fija el perfil, no el nombre del archivo del certificado.

El síntoma siempre tiene la misma forma

Un perfil de conexión se cambia de un nombre de host a una dirección IP, o se renueva de un certificado que llevaba un nombre DNS a uno que solo lleva direcciones, y el túnel deja de negociar. Nada cambió en la ruta de red. El cliente llega al par, recibe un certificado y rechaza la identidad del par porque el identificador que se le dijo que esperara no está representado en un campo que acepte. Las renovaciones son el desencadenante habitual, ya que el certificado de reemplazo suele venir de una plantilla distinta de la que sustituye.

Ambos lados registran entonces algo inútil, por lo que el fallo suele informarse como un problema de certificado. El registro del cliente puede nombrar la identidad que quería, y ese nombre es la pista que busca, no la fecha de caducidad.

Empareje el tipo de identificador, no solo el valor

Un SAN dNSName y un SAN iPAddress son campos distintos con reglas de coincidencia distintas, así que un certificado que lleva 203.0.113.10 como cadena DNS no satisface a un cliente que espera una identidad IP. Los validadores modernos ignoran en gran medida el nombre común, así que la etiqueta amable en los detalles del certificado no demuestra nada sobre lo que coincidirá. Si un nombre de host se sustituyó por una dirección durante la resolución de problemas, asuma que la identidad esperada se movió con él hasta que lo haya comprobado. Compare la cadena del perfil con la cadena del SAN carácter por carácter, porque un punto final o un espacio de más basta.

Los comodines son una comodidad solo para DNS y siguen sus propias reglas de coincidencia, que es otra razón por la que un perfil basado en IP nunca debería confiar en ellos.

Averigüe dónde guarda cada cliente la expectativa

En strongSwan, el valor que se compara con el certificado proviene del ajuste de identidad del par: rightid en la configuración clásica, o el id de una sección de conexión remota en swanctl. La documentación sobre interoperabilidad con Apple IKEv2 es útil aquí porque detalla las convenciones de identidad que usa un cliente guiado por perfil, y esas convenciones explican una clase de desajuste que en la red parece aleatorio.

Los perfiles de configuración de Apple llevan un campo de identificador remoto, y el valor de ahí es lo que comprueba el cliente, no la dirección del servidor en los ajustes de conexión. Los clientes de Windows y de dispositivos tienen cada uno su propio campo con su propio valor predeterminado, y el predeterminado suele seguir la dirección que usted escribió. Cuando dos campos discrepan, gana el que el cliente realmente lee, y rara vez es el que usted editó.

Repare el perfil o el certificado, deliberadamente

Inspeccione el certificado del par con herramientas aprobadas y enumere las entradas SAN con sus tipos antes de cambiar nada. Esa inspección no necesita clave privada ni carga, y resuelve la cuestión en segundos. Si el despliegue pretende una identidad DNS, el certificado debe llevarla como entrada dNSName, y si pretende una dirección, el certificado necesita una entrada iPAddress para exactamente esa dirección.

Cuando el certificado es incorrecto, solicite al operador uno corregido con el identificador esperado concreto. Cuando el perfil es incorrecto, corrija el perfil y deje el certificado en paz. Desactivar la validación de identidad hace desaparecer el error y elimina la comprobación de que el túnel habla con el par que usted pretendía.

Documente la identidad esperada por plataforma de cliente, porque un valor que un cliente deriva automáticamente puede necesitar ser explícito en otro.

Dé a la solicitud de renovación cuatro datos

Anote el identificador esperado y su tipo, las entradas SAN que el certificado actual tiene realmente, el cliente y la versión que hacen la comprobación, y el texto exacto del error. Una solicitud de renovación construida con esas cuatro líneas obtiene el certificado correcto a la primera, en lugar de otro con el mismo nombre de archivo familiar.