2

I am getting quite a weird trouble here with my puppet configuration.

On client and server (debian-squeeze), same version of puppet, clock synchronized.

Things were going great until I decided to install puppet-dashboard, I don't know at which step this lead to a failure, but here are the symptoms:

I have no certificate between the client and the server; I create on on client side which I send to server through this command:

puppetd --test --waitforcert 50

on the server side:

root@puppet:/var/lib/puppet/ssl# puppetca --list --all
  dev.goeland.lan (53:C8:AE:21:F0:64:FC:B8:7C:AD:7F:7A:1C:80:B0:4C)
root@puppet:/var/lib/puppet/ssl# puppetca -s dev.goeland.lan
notice: Signed certificate request for dev.goeland.lan
notice: Removing file Puppet::SSL::CertificateRequest dev.goeland.lan at '/var/lib/puppet/ssl/ca/requests/dev.goeland.lan.pem'
root@puppet:/var/lib/puppet/ssl# puppetca --list --all
+ dev.goeland.lan (FC:1A:E5:1F:D7:A3:C4:4A:B6:1A:7F:C6:4A:6E:07:55)
root@puppet:/var/lib/puppet/ssl#

First, I don't understand why the fingerprint changes : before being signed, the certificate is like *:4C, and it turns into *.55. Maybe this is a correct behavior?

Then, from client:

root@dev:/var/lib/puppet/ssl# puppetd --test 
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for dev.goeland.lan
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
root@dev:/var/lib/puppet/ssl#

Client refuses server certificate, while it has just been signed a the previous step!

Can anyone help me on this one?

Thanks a lot!

philippe
  • 2,303
  • 4
  • 32
  • 53
  • A side note: Is there a reason you're running such an old version of Puppet? The newer versions have a ton of bugfixes, and a much improved command-line interface. – Martijn Heemels Apr 19 '12 at 21:40
  • Waoo! How can you know my version of puppet? Indeed I have installed puppet with my package manager which could provide older versions than the most recent ones. Thanks for your answer, I will upgrade anyway my version of puppet (by installing from gem, I think) and come back on this. But this still doesn't explain why these fingerprints are different, and why the installation (again with aptitude) of pouppet-dashboard has broken the certificate verification :/ – philippe Apr 20 '12 at 07:48
  • 1
    I could tell from the commands you used. The newer versions have a single executable with subcommands, like `puppet agent --test`, `puppet master`, `puppet ca list`, etc. If you prefer packages over gems, Puppet Labs has official apt and yum repos available. I'm sorry that I don't know the answer to your fingerprint question. If you don't find an answer here, you could also ask on IRC. – Martijn Heemels Apr 20 '12 at 14:38

1 Answers1

0

The first fingerprint is that of the request. This should match the fingerprint on the client side, which puppet also prints in more recent versions.

After puppetca signs the request it deletes it (you can see it in the output) and the second fingerprint is that of the signed request.

The changing fingerprint is not the problem you are having. Most likely the clocks of the two machines are not in sync. Check the time on both machines and set the time of the client to something that is within a minute of the puppet master. And of course, make sure puppet configures ntpd for you.

chutz
  • 7,888
  • 1
  • 29
  • 59