Échec du certificat d'agent de marionnette

J'ai un maître / agent de marionnettes configuré et j'ai réussi à signer le certificat de l'agent sur le maître. Cependant, lorsque je cours, puppet agent --testj'obtiens un échec qui ressemble à ceci:

Warning: Unable to fetch my node definition, but the agent run will continue:  
Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com]  
Info: Retrieving plugin  
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com]  
Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com] Could not retrieve file metadata for puppet://hostname.domain.com/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com]  
Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com]  
Warning: Not using cache on failed catalog   
Error: Could not retrieve catalog; skipping run  
Error: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=hostname.domain.com]

la hostname.domain.comest le maître

Comment puis-je réparer ça? Je me suis assuré que les deux horloges sont au bon moment dans le même fuseau horaire, j'ai tout supprimé dans le /var/lib/puppet/sslrépertoire des agents et j'ai démissionné, je ne sais pas quoi faire d'autre.

— John Smith
source

Votre maître semble utiliser un certificat différent de celui auquel votre client fait confiance? Le certificat de maîtrise a-t-il changé?

— Shane Madden

@ShaneMadden Je ne le pense pas ... dois-je nettoyer et révoquer les certificats maîtres et clients? Je n'ai pas du tout dérangé avec les certificats maîtres, mais voici à quoi ressemble la sortie de "puppet cert list --all": + "masterhost.domain.com" (SHA1) E1: F7: 6A: 21: CB: CD: xx: xx: xx: xx ... + "agenthost.domain.com" (SHA256) 5A: D9: 7B: 96: 0B: FF: E4: 87: 58: AF: 00: xx: xx: xx : xx ..

— John Smith

Et c'est masterhost.domain.comle même que hostname.domain.comdans votre question, non? Essayons cela, nous verrons si les certificats vérifient manuellement; exécutez openssl s_client -connect masterhost.domain.com:8140 -showcerts-le et copiez les données du certificat (commence par -----BEGIN CERTIFICATE-----, incluez cette ligne et la ligne de certificat de fin) dans un nouveau fichier, puis exécutez openssl verify -CAfile /var/lib/puppet/ssl/certs/ca.pem /path/to/file/from/last/command-le et voyez s'il vérifie.

— Shane Madden

@ShaneMadden Il semble que quelque chose ne va pas .... Lorsque j'ai exécuté la commande "-showcerts", cela m'a donné deux certificats "begin" et "end", j'ai donc essayé d'ajouter d'abord l'un d'entre eux à un nouveau fichier, et j'ai obtenu ceci: / var / lib / puppet / ssl / ca / test: /CN=masterhost.domain.com erreur 7 à la recherche de profondeur 0: échec de la signature du certificat 22297: erreur: 0407006A: routines rsa: RSA_padding_check_PKCS1_type_1: le type de bloc n'est pas 01: rsa_pk1.c: 100: 22297: erreur: 04067072: routines rsa: RSA_EAY_PUBLIC_DECRYPT: contrôle de remplissage Failed: rsa_eay.c: 697: 22297: erreur: 0D0C5006: ASN1 encodage routines: ASN1_item_verify: vice - président exécutif lib: a_verify.c: 173:

— John Smith

C'est étrange. Il semble qu'il envoie le certificat racine en plus du certificat du serveur dans la connexion, alors peut-être comparez-vous simplement le contenu du deuxième certificat -showcertsavec le contenu de /var/lib/puppet/ssl/certs/ca.pem- ils devraient être identiques?

— Shane Madden

Réponses:

Recréez la configuration complète du certificat client. Cela a toujours résolu tous les problèmes de certification que nous avons rencontrés dans le passé. L'instruction suivante suppose que le nom d'hôte de votre agent est agenthost.hostname.com

Sur le client, supprimez tous les certificats stockés, y compris l'autorité de certification:

find /var/lib/puppet/ssl -name '*.pem' -delete

Sur le maître, supprimez les CSR en attente ou les anciens certificats clients pour ce client:

find /var/lib/puppet/ssl -name agenthost.domain.com.pem -delete

Ensuite, sur le client, reconnectez-vous au maître et envoyez un CSR:

puppet agent -t --waitforcert=60

et lorsqu'il attend (si vous n'avez pas activé la signature automatique activée), le maître approuve le CSR pour qu'un nouveau certificat client soit renvoyé:

puppet cert sign agenthost.domain.com

Cela devrait obliger l'agent à télécharger à nouveau les certificats de CA fantoche et à réappliquer son propre certificat.

Nous avons dû utiliser cette procédure dans le passé lorsque nous avons changé de serveur de marionnettes et que les certificats de l'autorité de certification ont changé, ou lorsque nous avons reconstruit un hôte avec le même nom d'hôte.

Assurez-vous que votre agent connaît son véritable nom d'hôte complet; utilisez la commande 'hostname' pour vous assurer que c'est ce que vous attendez.

— Steve Shipway
source

Le Maître, puppet cert clean ‘agentName’travaille pour moi. RHEL Puppet Enterprise emplacement: /etc/puppetlabs/puppet/ssl. Et j'ai synchronisé l'heure entre le maître et l'agent.

— Ivan Chau

Puppet Enterprise et la nouvelle Puppet 4 stockent leurs certificats sous / etc / puppetlabs / puppet / ssl, comme mentionné ci-dessus. L'emplacement / var / lib / puppet / ssl est destiné aux éditions de la communauté Puppet 2.x et 3.x.

— Steve Shipway

J'ai le même problème. J'ai mis en place un environnement vagabond avec un marionnettiste et plusieurs clients. Le problème est que lorsque je détruis et crée le marionnettiste, les clients détectent le nouveau marionnettiste comme un imposteur.

La suppression /etc/puppet/sslsur le client résout le problème.

N'oubliez pas que votre configuration SSL sera mise en cache, donc un redémarrage du maître de marionnettes est nécessaire, si vous décidez de supprimer également votre /etc/puppet/sslsur cet hôte:

sudo /etc/init.d/puppetmaster restart

— adrianlzt
source

service puppetserver restartcorrigé pour moi

— spuder