TL;DR : si le journal Puppet est rempli d'erreurs « SSL_CTX_use_PrivateKey: key values mismatch » mais qu'un agent puppet lancé à la main fonctionne, redémarre le service Puppet, car il a une clé privée obsolète en RAM.

Sur un serveur, je constate que des modifications de configurations prévues dans mon code Puppet n'ont pas été déployées. J'exécute l'agent puppet à la mano (puppet agent -t). Puppet applique des changements, qui, d'après l'historique du dépôt git contenant le code Puppet, datent de plusieurs semaines.

pgrep -x puppet (voir actualiser sa manière de chercher un processus) et systemctl status puppet confirment que l'agent puppet tourne pourtant en tâche de fond.

Je consulte le journal de Puppet (je l'ai rangé dans /var/log/puppet/puppetagent.log avec une configuration spécifique pour rsyslog, mais, par défaut, il est dans /var/log/syslog) et j'y trouve plein d'erreurs « SSL_CTX_use_PrivateKey: key values mismatch ». À chacune de ses tentatives de lancement, Puppet crache cette erreur.

Je pense à une bourde au niveau du réseau genre l'adresse IP ou l'adresse MAC du serveur Puppet (puppetmaster) est en double sur le réseau. Ça expliquerait un comportement du type "ça marche (quand je lance l'agent Puppet à la main), ça marche pas (d'après le journal)" : en fonction de quelle machine cause en dernier, le trafic est envoyé à la mauvaise, et la validation x509 joue parfaitement l'un de ses rôles, l'authentification du pair, et fait capoter la connexion. Je détecte aucune anomalie avec nos outils genre Netdisco ou SSH (qui, dans sa config' par défaut, vérifie l'empreinte d'un serveur à chaque connexion).

A posteriori, il y avait trois indices simples pour invalider cette hypothèse : 1) d'après le journal Puppet, il n'y a pas d'aspect aléatoire dans le dysfonctionnement (ce qui arrive rarement lors d'un conflit réseau) ; 2) un unique serveur était concerné par le problème ; 3) il est improbable que la machine usurpatrice ait, comme par hasard, un puppetmaster en écoute (sans ça, pas d'échange dans le bon protocole, donc pas d'erreur x509).

Je cherche sur le web et je trouve la ressource pointée par ce shaarli.

On a effectivement changé le certificat x509 du client Puppet (car renommage de la machine, de mémoire). À chaque exécution, l'agent puppet lancé à la mano récupère le certificat et sa clé privée en vigueur sur le disque dur. L'agent lancé par systemd qui tourne en tâche de fond a visiblement la mauvaise clé privée (ou le mauvais certificat) dans la RAM… Un systemctl restart puppet et ça repart.