Certificado IKEv2 e SAN: por que falla a comprobación de identidade

A cadea do seu certificado chega a unha CA de confianza, as datas son correctas e o par segue negándose a completar a fase 1 cun erro de identidade. O alcance e unha sinatura válida son só a metade do que comproba un cliente IKEv2. A outra metade é se a identidade que espera aparece no certificado no campo correcto, e esa expectativa fíxaa o perfil, non o nome do ficheiro do certificado.

O síntoma sempre ten a mesma forma

Un perfil de conexión cámbiase dun nome de host a un enderezo IP, ou renovase dun certificado que levaba un nome DNS a un que só leva enderezos, e o túnel deixa de negociar. Nada cambiou na ruta de rede. O cliente chega ao par, recibe un certificado e rexeita a identidade do par porque o identificador que se lle dixo que agardase non está representado nun campo que acepta. As renovacións son o desencadeante habitual, xa que o certificado de substitución adoita vir dun modelo distinto do que substitúe.

Entón ambos os lados rexistran algo inútil, polo que o fallo adoita informarse como un problema de certificado. O rexistro do cliente pode nomear a identidade que quería, e ese nome é a pista que busca, non a data de caducidade.

Emparexe o tipo de identificador, non só o valor

Un SAN dNSName e un SAN iPAddress son campos distintos con regras de coincidencia distintas, así que un certificado que leva 203.0.113.10 como cadea DNS non satisfai un cliente que espera unha identidade IP. Os validadores modernos ignoran en gran medida o nome común, así que a etiqueta amigable nos detalles do certificado non demostra nada sobre o que coincidirá. Se un nome de host se substituíu por un enderezo durante a resolución de problemas, asuma que a identidade esperada se moveu con el ata que o comprobase. Compare a cadea do perfil coa cadea do SAN carácter por carácter, porque un punto final ou un espazo de máis abonda.

Os comodíns son unha comodidade só para DNS e seguen as súas propias regras de coincidencia, que é outra razón pola que un perfil baseado en IP nunca debería confiar neles.

Averigüe onde garda cada cliente a expectativa

En strongSwan, o valor que se compara co certificado vén do axuste de identidade do par: rightid na configuración clásica, ou o id dunha sección de conexión remota en swanctl. A documentación sobre interoperabilidade con Apple IKEv2 é útil aquí porque detalla as convencións de identidade que usa un cliente guiado por perfil, e esas convencións explican unha clase de desaxuste que na rede parece aleatorio.

Os perfís de configuración de Apple levan un campo de identificador remoto, e o valor de aí é o que comproba o cliente, non o enderezo do servidor nos axustes de conexión. Os clientes de Windows e de dispositivos teñen cada un o seu propio campo co seu propio valor predeterminado, e o predeterminado adoita seguir o enderezo que vostede escribiu. Cando dous campos discrepan, gaña o que o cliente le realmente, e raramente é o que vostede editou.

Repare o perfil ou o certificado, deliberadamente

Inspeccione o certificado do par con ferramentas aprobadas e liste as entradas SAN cos seus tipos antes de cambiar nada. Ese exame non necesita clave privada nin carga, e resolve a cuestión en segundos. Se o despregamento pretende unha identidade DNS, o certificado debe levala como entrada dNSName, e se pretende un enderezo, o certificado necesita unha entrada iPAddress para exactamente ese enderezo.

Cando o certificado é incorrecto, solicite ao operador un corrixido co identificador esperado concreto. Cando o perfil é incorrecto, corrixa o perfil e deixe o certificado en paz. Desactivar a validación de identidade fai desaparecer o erro e elimina a comprobación de que o túnel fala co par que vostede pretendía.

Documente a identidade esperada por plataforma de cliente, porque un valor que un cliente deriva automaticamente pode necesitar ser explícito noutro.

Dea á solicitude de renovación catro datos

Anote o identificador esperado e o seu tipo, as entradas SAN que o certificado actual ten realmente, o cliente e a versión que fan a comprobación, e o texto exacto do erro. Unha solicitude de renovación construída con esas catro liñas obtén o certificado correcto á primeira, en lugar doutro co mesmo nome de ficheiro familiar.