On Thu, Jun 14, 2012 at 9:44 AM, jcbollinger <john.bollin...@stjude.org> 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 >> certficate. > > 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 > CSR.
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. 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 master. If I point that node to my top-level Master (via entry in /etc/hosts), the `puppet agent --test --noop` invocation works without error. >> [...] 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 /var/lib/puppet/ssl/private_keys/agent.pem 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: CD:2C:44:54:40:B3:8A:A1:30:73:49:95:95:12:CD:54 > 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. 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. The problem seems to lie with the subordinate masters acting as Puppet Masters. Thanks for the suggestions. Do please keep them coming! Cheers, Scott -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
