Private key troubles after a new install and a reboot

[Tom]

Ok, I'm new to puppet, but I've got everything working for my setup.
Almost.

I'm trying to set up a new server, using cobbler, and then puppet.

CentOS 6.2
Puppet 2.7.11
Cobbler 2.0.11

I have things set up so I can use kickstart to install the server on
boot. It installs puppet and facter from the puppetlabs repos and the
snippet $SNIPPET('puppet_install_if_enabled') and
$SNIPPET('puppet_register_if_enabled') is called in the %post section.

I have the puppet server set up to autosign (for now).

When the %post part of the kickstart install is run, I see the machine
connecting to the puppetmaster, and it sets up the credentials:

info: Could not find certificate for 'client.domain.com'
info: Could not find certificate_request for 'client.domain.com'
notice: client.domain.com has a waiting certificate request
notice: Signed certificate request for client.domain.com
notice: Removing file Puppet::SSL::CertificateRequest
client.domain.com at '/var/lib/puppet/ssl/ca/requests/
client.domain.com.pem'




But when I reboot the machine, if I try to run puppetd again manually,
I'm getting a private key error:


puppetd --server puppet.domain.com --test --waitforcert 15
err: Could not request certificate: The certificate retrieved from the
master does not match the agent's private key.
Certificate fingerprint: E5:B1:52:B2:DC:DE:8C:DE:A7:AF:ED:
19:C8:E3:F5:12
To fix this, remove the certificate from both the master and the agent
and then start a puppet run, which will automatically regenerate a
certficate.
On the master:
puppet cert clean client.domain.com
On the agent:
rm -f /var/lib/puppet/ssl/certs/client.domain.com.pem
puppet agent -t

If I do what it says, then puppet gets new certs (I guess that's what
it's doing) and everything works fine.

But I cannot figure out why that is required. What is going wrong?
Shouldn't it be able to come up and work without jumping through these
extra hoops?

Tom

[Russell Van Tassell]

Any chance you've hit one of those conditions where package defaults point the SSLDIR to /var/lib/puppet/ssl instead of /etc/puppet/ssl? I've seen this, specifically, when moving between RedHat/CentOS RPMs and gems, just as an example. (or, they're specified one way in your puppet.conf, and expected/defaulted differently in the package ... so in your second and subsequent runs, you'll see the problem).

You should be able to easily reproduce this by blowing away all your puppet configs and SSL information on a "new" client and cleaning them out on the server ... then running "puppet agent --test" to see what it does (should re-request certs, etc). Once it's done, immediately run it again to see if it tries to re-request (and fail) the certs.

Hope that helps...

Russell

Tom

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Markus Falb]

On 29.2.2012 21:55, Tom wrote:
> Ok, I'm new to puppet, but I've got everything working for my setup.
> Almost.
>
> I'm trying to set up a new server, using cobbler, and then puppet.
>
> CentOS 6.2
> Puppet 2.7.11
> Cobbler 2.0.11
>
> I have things set up so I can use kickstart to install the server on
> boot. It installs puppet and facter from the puppetlabs repos and the
> snippet $SNIPPET('puppet_install_if_enabled') and
> $SNIPPET('puppet_register_if_enabled') is called in the %post section.

...

> puppetd --server puppet.domain.com --test --waitforcert 15
> err: Could not request certificate: The certificate retrieved from the
> master does not match the agent's private key.
> Certificate fingerprint: E5:B1:52:B2:DC:DE:8C:DE:A7:AF:ED:
> 19:C8:E3:F5:12

I think it means that the new installed client created a key and csr in
%post as expected but the master already had a certificate for that
machine. Before you reinstall you have to clean the existing cert on the
master.

--
Kind Regards, Markus Falb

[Tom]

Yes indeed, that was it!

Things were getting switched around from /var/lib/puppet/ssl to /etc/puppet/ssl.....

Thanks for the help!

Tom

On Wednesday, February 29, 2012 1:21:31 PM UTC-8, Russell VT wrote:

Any chance you've hit one of those conditions where package defaults point the SSLDIR to /var/lib/puppet/ssl instead of /etc/puppet/ssl? I've seen this, specifically, when moving between RedHat/CentOS RPMs and gems, just as an example. (or, they're specified one way in your puppet.conf, and expected/defaulted differently in the package ... so in your second and subsequent runs, you'll see the problem).

You should be able to easily reproduce this by blowing away all your puppet configs and SSL information on a "new" client and cleaning them out on the server ... then running "puppet agent --test" to see what it does (should re-request certs, etc). Once it's done, immediately run it again to see if it tries to re-request (and fail) the certs.

Hope that helps...

Russell