strongSwan send_cert : quand le certificat IKE est envoyé

Les passerelles journalisent les échecs d’authentification liés aux certificats, et le premier réflexe est d’ajouter une autre CA au destinataire. Cela suppose que le certificat est arrivé et qu’il a été rejeté. L’autre possibilité est qu’il n’ait jamais été envoyé, et c’est la politique de connexion de l’émetteur qui en décide. Déterminez lequel des deux s’est produit avant de toucher à la confiance.

Ce que send_cert contrôle réellement

L’authentification par certificat exige que le certificat d’entité finale du pair atteigne l’autre côté via l’échange IKE ou un approvisionnement préalable. Dans swanctl, le réglage de connexion send_cert détermine si ce point de terminaison inclut sa charge de certificat : jamais, toujours ou ifasked. La valeur par défaut ifasked l’envoie en réponse à une demande de certificat du pair. Demander un certificat est un réglage distinct, car demander son certificat à l’autre côté n’est pas la même chose que d’offrir le sien.

Les anciens déploiements ipsec.conf utilisaient leftsendcert et rightsendcert, et ces noms correspondent aux rôles local et distant, pas directement à swanctl.

Lisez une tentative avant de modifier la connexion

Diagnostiquez à partir d’une seule tentative contrôlée, et non de l’impression générale que des certificats sont en jeu. La politique comme l’association active sont inspectables.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

La liste des connexions montre la valeur configurée de send_cert, et la liste des SA montre quelles connexions ont réellement été établies. Le journal ajoute des détails de négociation : si une demande de certificat a été reçue et si une charge de certificat est sortie. Un échec d’authentification générique n’identifie pas un problème de livraison, cherchez donc l’échange précis avant de conclure quoi que ce soit. Notez l’horodatage de la tentative pour que la fenêtre du journal couvre toute la poignée de main.

La confiance du destinataire est une décision distincte

Livraison et confiance sont des propriétés différentes, et corriger l’une ne corrige pas l’autre. Un destinataire doit détenir l’ancre de confiance prévue, recevoir une chaîne utilisable et correspondre à l’identité attendue du pair. Un certificat d’entité finale qui arrive sans son intermédiaire échoue encore à un contrôle de chaîne strict. À l’inverse, installer une CA n’oblige nullement un pair à envoyer son certificat.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

L’inspection montre quel émetteur a signé le certificat et quand il expire, et c’est à cela que l’ancre du destinataire doit correspondre. Faites confiance à la CA émettrice que possède le déploiement, pas à chaque intermédiaire de la chaîne, car promouvoir chaque intermédiaire en racine élargit la confiance bien au-delà d’un seul pair. Laissez la vérification d’identité active, car une connexion qui ne réussit qu’avec la validation désactivée n’est pas une correction. Là où la chaîne est incomplète, réparez l’approvisionnement plutôt que la politique de l’émetteur.

Ne changez l’émetteur qu’avec des preuves

Lorsque le journal montre que le certificat n’a jamais été envoyé et que le destinataire l’a bien demandé, passer send_cert à always est un changement justifié pour cette connexion. Appliquez-le dans la configuration swanctl, rechargez les connexions et établissez une nouvelle session au lieu de réutiliser la SA existante. Confirmez que la charge de certificat apparaît maintenant et que le destinataire l’accepte face à l’ancre prévue. Si rien ne change, la panne se situait finalement du côté de la confiance et le réglage de l’émetteur n’en était pas la cause.

Inscrivez l’échange observé, l’ancre et la vérification qui en résulte dans le registre des changements. Une correction de certificat qui ne peut pas être décrite en ces termes est une coïncidence.