Le nom d'hôte de la marionnette ne correspond pas au certificat du serveur

J'essaie de configurer une machine virtuelle Ubuntu avec une marionnette installée afin que je puisse tester localement notre configuration de production. J'ai du mal à faire en sorte que marionnettiste et marionnette se parlent. Permettez-moi de vous guider dans mes démarches. (Le serveur hostnameest un nom de domaine complet au format "web1.xxx.xxx.net").

Donc tout d'abord, j'efface tous les fichiers pem (sauf les pems CA bien sûr) du /etc/puppet/sslrépertoire afin que je puisse faire un nouveau départ. puppetca --listne renvoie aucun résultat.

Ensuite, je cours puppetd --testpour générer un CSR pour le marionnettiste. puppetca --listinclut désormais mon nom d'hôte ("web1.xxx.xxx.net").

Alors je cours puppetca --sign web1.xxx.xxx.net. Maintenant, il puppetca --listest à nouveau vide - tout fonctionne bien jusqu'à présent.

Enfin, je cours à puppetd --testnouveau. J'obtiens la sortie suivante:

err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

La liste du contenu du /etc/puppet/sslrépertoire affiche les fichiers PEM avec le nom de serveur correct, qui correspond à mon hostname. Quelqu'un a des idées sur la façon d'attaquer ce problème?

L'erreur est due au fait que le client se connecte par défaut au nom d'hôte du serveur «marionnette» mais que le certificat présenté n'a pas «marionnette» comme objet ou comme attribut SubjectAltName.

Pour y remédier, vous pouvez (en choisir un):

1. au lieu d'initialiser le certificat de votre marionnettiste en exécutant puppetd, initialisez-le en exécutant puppetmasterd- cela entraînera le nom de sujet du certificat pour inclure "marionnette".

2. au lieu de laisser les choses au hasard, vous pouvez utiliser puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net- l'option certdnsnames spécifie une liste de SubjectAltNames qui seront inclus dans le certificat; il doit avoir une liste séparée par deux-points de tout nom qu'un client utiliserait pour contacter le serveur.

3. au lieu de simplement exécuter puppetd --testsur le client, exécutez de puppetd --test --server=web1.xx.xx.xx.netsorte que le nom du serveur auquel le client se connecte soit celui qui existe réellement dans le certificat présenté par le serveur.

Consultez l'excellente entrée de blog de masterzen pour un dépannage supplémentaire: Puppet SSL Explained

Avez-vous vérifié le fichier journal de puppetmaster? J'ai trouvé le même problème et constaté que le serveur enregistre les informations du certificat:

[2012-02-28 16:21:09] INFO  
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=ca
        Validity
            Not Before: Feb 26 16:32:46 2012 GMT
            Not After : Feb 24 16:32:46 2017 GMT
        Subject: CN=ubuntu.localdomain

Le champ Subject montre que le CN est "ubuntu.localdomain", j'ai donc exécuté la marionnette en faisant:

puppetd -t --server=ubuntu.localdomain --fqdn=myfqdn

J'espère que cela t'aides :-)

En plus de ce que Pau a répondu, je voudrais juste souligner que vous pouvez inspecter le certificat de marionnettiste en utilisant:

openssl x509 -text -in /var/lib/puppet/ssl/certs/<hostname_of_puppet_master>

Assurez-vous ensuite que vous utilisez exactement le même nom d'hôte lorsque vous êtes sur le client:

puppetd --server <hostname_of_puppet_master> <etc>

Les deux serveurs sont-ils capables de se résoudre mutuellement? Je suppose que puisque vous l'utilisez, vous risquez de manquer la résolution de nom. Si vous n'utilisez pas DNS pour laisser les serveurs se résoudre, vous devez ajouter des entrées à votre /etc/hostsfichier sur les deux serveurs.

Puppet nécessite que les noms d'hôte se résolvent aux IP correctes, sans cela, vous obtiendrez l'erreur que vous avez mentionnée. Vous devrez peut-être recréer des certificats après cela. Les deux machines devraient être en mesure de faire un ping chacune par nom d'hôte.

Une autre chose à laquelle vous devez faire attention avec les machines virtuelles est que vous synchronisez les heures sur les serveurs. Si vous ne le faites pas, il est probable que les certificats seront invalides.