On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu <n...@puppetlabs.com> wrote: > A few other thing you can try is to run the web brick server and run > puppet master --debug --no-daemonize on the sub master and see if that > give any more info. You can also try enabling CA on the sub-master and > check what you get back from another test client and see what you > receive the right CA file on initial connection and what CA cert signs > that client's CSR. That's all I can think of.
Trying to run `puppet master --debug --no-daemonize` failed. The process terminated with the same error: Could not prepare for execution: The certificate retrieved from the master does not match the agent's private key. I revoked the subordinate master's key, and then executed `puppet agent --test -d` from that subordinate master. I noticed during the output that it was creating the /var/lib/puppet/ssl/ca directory, despite having "ca = false" in the puppet.conf file. I looked a little closer at the http://docs.puppetlabs.com/guides/scaling_multiple_masters.html instructions, and say to my chagrin that the location of the "ca = false" in my config file was _not_ in the stanza as directed there. I updated my puppet.conf to strictly follow those instructions: [main] logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl ca_server = top-level-master.domain dns_alt_names = 'subordinate-master-1.domain,puppetmaster.domain' [agent] classfile = $vardir/classes.txt localconfig = $vardir/localconfig server = top-level-master.domain [server] # for Passenger ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY [master] ca = false On this subordinate master, I executed `sudo rm -rf /var/lib/puppet/ssl`; and on the top-level master I executed `puppet cert clean subordinate-master-1.domain`. On the subordinate master, I then executed `puppet agent --test --noop`: # puppet agent --test --noop info: Creating a new SSL key for subordinate-master-1.domain warning: peer certificate won't be verified in this SSL session info: Caching certificate for ca warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for subordinate-master-1.domain info: Certificate Request fingerprint (md5): 2D:F2:2A:A5:BD:56:D4:41:5A:B3:22:AA:A5:97:3D:66 warning: peer certificate won't be verified in this SSL session err: Could not request certificate: Error 400 on SERVER: CSR 'subordinate-master-1.domain' contains subject alternative names (DNS:subordinate-master-1.domain, DNS:puppetmaster.domain), which are disallowed. Use `puppet cert --allow-dns-alt-names sign subordinate-master-1.domain` to sign this request. Exiting; failed to retrieve certificate and waitforcert is disabled On the top-level master, I executed `puppet cert --allow-dns-alt-names sign subordinate-master-1.domain`. On the subordinate master I re-ran `puppet agent --test --noop`. The certificate, private key, and CA cert were all installed properly. Now on the subordinate master I can run `puppet master --debug --no-daemonize` without errors. I restarted Apache, and from this subordinate master I ran `puppet agent --test --noop -d --server subordinate-master-1.domain --ca_server top-level-master.domain`. No errors! I've repeated this on one of the other subordinate masters I'd previously -- and erroneously -- configured, and enjoyed the same success there. The client node with which I've been testing can now successfully connect to the subordinate master without error. Thank you very, very much for working through this with me. 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.
