Certificat IKEv2 et SAN : pourquoi la vérification d'identité échoue

La chaîne de votre certificat remonte à une CA de confiance, les dates sont bonnes, et le pair refuse toujours de terminer la phase 1 avec une erreur d'identité. L'accessibilité et une signature valide ne représentent que la moitié de ce qu'un client IKEv2 vérifie. L'autre moitié est de savoir si l'identité attendue figure dans le certificat au bon champ, et cette attente est fixée par le profil, pas par le nom de fichier du certificat.

Le symptôme a toujours la même forme

Un profil de connexion passe d'un nom d'hôte à une adresse IP, ou est renouvelé d'un certificat qui portait un nom DNS vers un certificat qui ne porte que des adresses, et le tunnel cesse de négocier. Rien n'a changé sur le chemin réseau. Le client atteint le pair, reçoit un certificat et rejette l'identité du pair parce que l'identifiant qu'il devait attendre n'est pas représenté dans un champ qu'il accepte. Les renouvellements sont le déclencheur habituel, car le certificat de remplacement provient souvent d'un modèle différent de celui qu'il remplace.

Les deux côtés journalisent alors quelque chose d'inutile, ce qui explique pourquoi la panne est généralement signalée comme un problème de certificat. Le journal du client peut nommer l'identité qu'il voulait, et ce nom est l'indice que vous cherchez, pas la date d'expiration.

Faites correspondre le type d'identifiant, pas seulement la valeur

Un SAN dNSName et un SAN iPAddress sont des champs différents avec des règles de correspondance différentes, donc un certificat qui porte 203.0.113.10 comme chaîne DNS ne satisfait pas un client qui attend une identité IP. Les validateurs modernes ignorent largement le nom commun, donc l'étiquette conviviale dans les détails du certificat ne prouve rien sur ce qui correspondra. Si un nom d'hôte a été remplacé par une adresse pendant le dépannage, supposez que l'identité attendue a suivi jusqu'à ce que vous ayez vérifié. Comparez la chaîne du profil à celle du SAN caractère par caractère, car un point final ou un espace superflu suffit.

Les jokers sont une commodité réservée au DNS et suivent leurs propres règles de correspondance, ce qui est une autre raison pour qu'un profil basé sur IP ne s'y fie jamais.

Trouvez où chaque client stocke l'attente

Dans strongSwan, la valeur comparée au certificat vient du réglage d'identité du pair : rightid dans la configuration classique, ou l'id d'une section de connexion distante dans swanctl. La documentation sur l'interopérabilité avec Apple IKEv2 est utile ici car elle expose les conventions d'identité qu'utilise un client piloté par profil, et ces conventions expliquent une classe d'incohérences qui paraissent aléatoires sur le réseau.

Les profils de configuration Apple portent un champ d'identifiant distant, et la valeur qui s'y trouve est ce que le client vérifie, pas l'adresse du serveur dans les réglages de connexion. Les clients Windows et les appliances ont chacun leur propre champ avec leur propre valeur par défaut, et la valeur par défaut suit souvent l'adresse que vous avez saisie. Lorsque deux champs se contredisent, celui que le client lit réellement l'emporte, et c'est rarement celui que vous avez modifié.

Réparez le profil ou le certificat, délibérément

Inspectez le certificat du pair avec des outils approuvés et listez les entrées SAN avec leurs types avant de changer quoi que ce soit. Cette inspection ne nécessite ni clé privée ni téléversement, et elle tranche la question en quelques secondes. Si le déploiement prévoit une identité DNS, le certificat doit la porter comme entrée dNSName, et s'il prévoit une adresse, le certificat a besoin d'une entrée iPAddress pour exactement cette adresse.

Lorsque le certificat est faux, demandez-en un corrigé à l'opérateur avec l'identifiant attendu précis. Lorsque le profil est faux, corrigez le profil et laissez le certificat tranquille. Désactiver la validation d'identité fait disparaître l'erreur et supprime la vérification que le tunnel parle au pair que vous vouliez.

Documentez l'identité attendue par plateforme cliente, car une valeur qu'un client déduit automatiquement peut devoir être explicite sur un autre.

Donnez quatre faits à la demande de renouvellement

Notez l'identifiant attendu et son type, les entrées SAN que le certificat actuel possède réellement, le client et la version qui font la vérification, et le texte exact de l'erreur. Une demande de renouvellement construite à partir de ces quatre lignes obtient le bon certificat du premier coup, au lieu d'un autre portant le même nom de fichier familier.