Le certificat de la passerelle est correct : pourquoi la connexion IKEv2 PEAP échoue quand même

Le certificat de votre passerelle VPN est valide, la chaîne se valide, et le client IKEv2 refuse toujours la connexion avec un message sur un intervalle de validité de certificat. Le premier réflexe est de réémettre le certificat de la passerelle ou de changer de méthode EAP, et les deux sont généralement faux. La tentative de connexion porte deux identités de serveur distinctes : le certificat de la passerelle utilisé par IKE, et le certificat présenté par ce qui termine PEAP. L’une est correcte, et l’autre est la raison pour laquelle le client s’est arrêté.

Deux identités, une seule tentative de connexion

Le certificat du profil VPN appartient à l’échange IKE : il prouve que la passerelle est le pair nommé par le profil, selon la stratégie IKE configurée. Le certificat qui échoue ici appartient à une autre conversation, la session TLS que PEAP ouvre avec ce qui authentifie l’utilisateur, souvent un serveur RADIUS comme NPS plutôt que la passerelle elle-même. Un troisième contrôle, les identifiants de l’utilisateur, a lieu à l’intérieur de cette session. Un mot de passe valide ne peut pas réparer un certificat de serveur expiré, et un certificat de passerelle valide ne peut pas se porter garant du point de terminaison PEAP.

Cette superposition explique pourquoi une erreur de certificat apparaît à un endroit où le seul certificat configuré était celui de la passerelle. Elle explique aussi pourquoi réémettre ce certificat ne change rien.

Lisez la ligne du journal en fonction de l’étape

Trouvez le message qui nomme la raison et les dates. Une plainte sur l’intervalle de validité à côté d’une erreur de sujet signifie que le serveur a rejeté le certificat qu’on lui a fourni, et non que l’utilisateur a rejeté la connexion. Trouvez ensuite l’étape : un journal charon de strongSwan affiche IKE_SA .* established avant que l’échange EAP commence, donc une erreur de certificat après cette ligne relève de l’identité EAP, tandis qu’une erreur avant celle-ci désigne la passerelle. Le texte d’étape dans le panneau de connexion d’un client Windows dit la même chose.

Vérifiez l’horloge du client avant de toucher au moindre certificat. Un appareil décalé de plusieurs heures produit la même erreur de validité qu’un certificat réellement expiré. Remettre l’horloge à l’heure est une correction de cinq secondes, et remplacer un certificat qui n’a jamais été le problème est une panne.

Déterminez quel point de terminaison termine PEAP

Dans une conception passerelle plus RADIUS, la passerelle transmet EAP et ne le termine pas. Le greffon eap-radius de strongSwan remet l’échange au serveur RADIUS, qui possède la session TLS de PEAP et son certificat. Corrélez une tentative échouée dans les deux journaux et confirmez quel processus a réellement choisi un certificat pour cette session.

Pour NPS, le certificat doit se trouver dans le magasin de l’ordinateur local, porter l’usage d’authentification du serveur, correspondre au nom attendu par les clients et être lisible par le compte de service. Les exigences de certificat de Microsoft pour NPS énumèrent ces conditions. Les autres serveurs EAP ont leurs propres règles de sélection, alors ne copiez pas les particularités de NPS dans un déploiement FreeRADIUS ni l’inverse. La règle qui tient dans les deux cas est que le point de terminaison qui termine PEAP possède le certificat que vous êtes sur le point de changer.

Remplacez le certificat là où EAP se termine

Renouvelez ou remplacez le certificat sur le point de terminaison qui termine PEAP, via la procédure prise en charge, en conservant l’usage d’authentification du serveur et le nom attendu. Installez la chaîne complète là où le service la cherche et accordez au service l’accès à la clé privée. Redémarrez ou reliez le service, car beaucoup de services gardent l’ancien certificat en mémoire et continuent de le présenter. Un fichier copié sur la machine ne prouve rien quant au certificat que le service présente réellement.

Confirmez le changement en corrélant la tentative suivante avec le journal propre au service, ou en inspectant le certificat présenté par la session. Si ce journal affiche encore l’ancienne empreinte, le redémarrage n’a pas pris.

Ne supposez pas que le fichier le plus récent d’un répertoire soit celui qui est utilisé. Une copie avec le bon nom et les mauvaises autorisations ne change rien. Jugez le changement à l’identité présentée, pas à l’horodatage d’un fichier.

Ce qu’il ne faut pas faire

Ne désactivez pas la validation PEAP et ne forcez pas une méthode interne plus faible pour contourner l’erreur. Cela change la stratégie et supprime la propriété d’authentification du serveur qui a justement attrapé le certificat expiré. Vous échangeriez un contrôle qui fonctionne contre une connexion qui fonctionne, et le prochain certificat expiré arriverait sans rien pour l’annoncer.

Ne prenez pas une connexion réussie d’un autre système d’exploitation comme preuve que le certificat est acceptable. Ce client peut utiliser une autre méthode EAP, un autre magasin de confiance ou aucune validation de serveur, si bien que son succès ne dit rien du contrôle qui a échoué ici. Gardez un test négatif délibéré, comme un certificat au mauvais nom ou une chaîne non fiable, qui échoue comme prévu. Si ce test passe maintenant, vous avez retiré un contrôle plutôt que réparé un certificat. Notez quelle identité a échoué, pour que la personne suivante ne reparte pas du certificat de la passerelle.