On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill wrote:
On Thu, Jun 14, 2012 at 9:44 AM, jcbollinger wrote:
On Tuesday, June 12, 2012 1:53:55 PM UTC-5, Scott Merrill wrote:
Could not prepare for execution: The certificate retrieved from the
master  does not match the agent's private key.
Certificate fingerprint: CD:2C:44:54:40:B3:8A:A1:30:73:49:95:95:12:CD:54
To fix this, remove the certificate from both the master and the agent
and then start a puppet run, which will automatically regenerate a
The agent should expect to retrieve a certificate that matches its own
private key only as part of a certificate signing transaction.  The error
therefore suggests that the agent does not recognize that it already has a
certificate, so that it issues a new CSR to the master.  If the master
already had a signed certificate for the client, however, then it would
return that certificate instead of signing the new one (this prevents rogue
nodes from hijacking existing nodes' configuration).  The existing
certificate would not match the private key of the client's newly-generated
In a multi-master environment, does each Puppet Master need to have a
copy of each node's certificate?  It was my (perhaps faulty)
understanding that any cert signed by the CA (and not revoked, if
using a CRL) would be accepted by any master.
No, the subordinate masters don't need the client cert. The cert is
verified by checking which CA signed the cert.
If I put the node's public certificate on the subordinate Master (in
/var/lib/puppet/ssl/certs/), `puppet agent --test --noop` pointing to
that subordinate master (via /etc/hosts) fails with the error message
as discussed here. The agent also receives the same error if it's
public key is in /var/lib/puppet/ssl/public_keys/ on the subordinate

If I point that node to my top-level Master (via entry in /etc/hosts),
the `puppet agent --test --noop` invocation works without error.
You want to make sure the subordinate master present the same CA pub
key as the top-level master.
[...] There error isn't a Puppet client
problem, because I get the same error when I run `openssl s_client
-connect hostX.domain:8140 -status`.

Surely openssl does not generate an identical message, because the one you
reported earlier contains puppet-specific bits.  Do you mean that openssl's
message matches some part in the middle?
Yes: the openssl output first shows the certificate info it has
gleaned from the remote, and then it will display the same mod_rails
error that I see from `puppet agent --test --noop -d`.
You could try adding a "-cert" argument pointing specifically to the client
certificate you installed.  If that made the handshake succeed then it would
strongly suggest that your problem is related to how or where the client
cert is installed.
I tried:
openssl s_client -connect hostX.domain:8140 -status -cert
/var/lib/puppet/ssl/certs/agent.pem -key

and received the same output: SSL information followed by the mod_rails error:
Could not prepare for execution: The certificate retrieved from the
master does not match the agent's private key.
Certificate fingerprint:
You could try adding a "-debug" argument.  You'll get a lot of low-level
stuff you probably don't need, but you should also get enough information to
trace the SSL protocol steps being performed.  That should show, I think,
whether the client is indeed issuing a new CSR to the server.
I only see the mod_rails error when using `puppet agent --test -d`.

I do see that /var/lib/puppet/ssl/ is being autorequired by the Puppet run.
You could check the logs on the subordinate and top-level masters.  One or
both should have something to say about the transaction.
I've looked through all the logs, and see nothing of interest. I've
got the following in my /etc/httpd/conf.d/puppet.conf on the
subordinate master:
ErrorLog /var/log/httpd/puppet_error.log
LogLevel debug
CustomLog /var/log/httpd/puppet_access.log combined
At the end of\ /var/log/httpd/puppet_error.log I see:
[Thu Jun 14 12:16:46 2012] [debug] ssl_engine_kernel.c(1884): OpenSSL:
Write: SSL negotiation finished successfully
I'm not an expert at SSL, but the debug output looks like a successful
SSL connection was established.

Because the top-level Puppet Master can successfully service the
node's request, I am led to believe that the SSL certificates are
installed and signed correctly on both the top-level Master and the
node. Yes.
Subordinate masters can function as clients of the top-level Master
successfully, so their certificates are installed and signed
correctly, at least for the agent context.
You only verified they have a working client cert, not that it's
presenting the correct CA pub key or server cert. An easy test is to
connect the subordinate master to itself and see if that works.

I would run the following tests:

puppet agent -t --server sub-master --ca_server master

puppet agent -t --server sub-master --ca_server master



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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 16 | next ›
Discussion Overview
grouppuppet-users @
postedJun 12, '12 at 6:54p
activeJun 15, '12 at 2:44a



site design / logo © 2022 Grokbase