Scott Merrill
2012-Jun-12 18:53 UTC
[Puppet Users] "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
I''m trying to set up a multi-tier Puppet Master configuration. A
top-level Puppet Master serves subordinate Puppet Masters, which in
turn serve the nodes. The top-level Master is also the Certificate
Authority for the entire infrastructure.
I''m using RHEL 6.1, Puppet 2.7.14, and mod_passenger.
I built the top-level Master without problems. I then built four
subordinate Masters. In the puppet.conf for each subordinate Master, I
added:
dns_alt_names =
''hostX.domain,puppetmaster,puppetmaster.domain''
(where hostX.domain is the FQDN of the server on which I was working)
First execution of `puppet agent --test` on each subordinate Master told me:
err: Could not request certificate: Error 400 on SERVER: CSR
''host.domain'' contains subject alternative names
(DNS:puppetmaster.domain,
DNS:hostX.domain), which are disallowed. Use `puppet cert
--allow-dns-alt-names sign hostX.domain` to sign this request.
Exiting; failed to retrieve certificate and waitforcert is disabled
On the top-level Master I executed the command as instructed. Next
execution of `puppet agent --test` from the subordinate Master
retrieved the signed certificate. Each subordinate Master can connect
to the top-level Master without error.
On each subordinate Master I next setup mod_passenger, so that these
hosts could server my Puppet clients.
I built a test client, and from the top-level Puppet Master I ran
`puppet cert generate test.domain`. I installed the generated files
onto the test machine. However, this test client is unable to connect
to any of the subordinate Masters. I get the following 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
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 hostX.domain
On the agent:
rm -f /var/lib/puppet/ssl/certs/hostX.domain
puppet agent -t
All four of my subordinate Puppet Masters yield the same error message
when the test node connects. What''s more, all four of them display the
same certificate fingerprint. 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`.
Each subordinate Master is using an /etc/httpd/conf.d/puppet.conf file
that looks like this:
Listen 8140
<VirtualHost *:8140>
ErrorLog /var/log/httpd/puppet_error.log
LogLevel warn
CustomLog /var/log/httpd/puppet_access.log combined
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /var/lib/puppet/ssl/certs/hostX.domain.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/hostX.domain.pem
SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem
# CRL checking should be enabled
# disable next line if Apache complains about CRL
#SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
# optional to allow CSR request, required if certificates
distributed to client during provisioning.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars
# The following client headers record authentication information
for down stream workers.
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
RackAutoDetect On
DocumentRoot /etc/puppet/rack/puppetmaster/public/
<Directory /etc/puppet/rack/puppetmaster/>
Options None
AllowOverride None
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Again, "hostX.domain" is the FQDN of each individual server.
I''m quite sure the solution is something simple, and I''m just
not
seeing it. I''d appreciate a nudge in the right direction.
Thanks,
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Felix Frank
2012-Jun-13 11:26 UTC
Re: [Puppet Users] "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
Hi, On 06/12/2012 08:53 PM, Scott Merrill wrote:> I built a test client, and from the top-level Puppet Master I ran > `puppet cert generate test.domain`. I installed the generated files > onto the test machine. However, this test client is unable to connect > to any of the subordinate Masters. I get the following error:I''m shooting in the dark here, but have you tried copying the generated certificates to you subordinate masters as well? I.e., in /var/lib/ssl/ca... HTH, Felix -- 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.
Scott Merrill
2012-Jun-13 13:42 UTC
Re: [Puppet Users] "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Wed, Jun 13, 2012 at 7:26 AM, Felix Frank <felix.frank@alumni.tu-berlin.de> wrote:> On 06/12/2012 08:53 PM, Scott Merrill wrote: >> I built a test client, and from the top-level Puppet Master I ran >> `puppet cert generate test.domain`. I installed the generated files >> onto the test machine. However, this test client is unable to connect >> to any of the subordinate Masters. I get the following error: > > I''m shooting in the dark here, but have you tried copying the generated > certificates to you subordinate masters as well? I.e., in /var/lib/ssl/ca...Thanks for the suggestion. I hadn''t tried that before. I just did, but it didn''t change the error message. I should have pointed out that each subordinate master has "ca false" in puppet.conf, to ensure that none of the subordinate masters try to do any CA stuff. All CA activities should only be performed on the top-level master. Any other suggestions are greatly appreciated. Thanks, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2012-Jun-14 13:44 UTC
[Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Tuesday, June 12, 2012 1:53:55 PM UTC-5, Scott Merrill wrote:> > I built a test client, and from the top-level Puppet Master I ran > `puppet cert generate test.domain`. I installed the generated files > onto the test machine. However, this test client is unable to connect > to any of the subordinate Masters. I get the following 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 > 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.> [...] 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? 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. 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. You could check the logs on the subordinate and top-level masters. One or both should have something to say about the transaction. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jlJkoEoHhCkJ. 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.
Scott Merrill
2012-Jun-14 16:27 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 9:44 AM, jcbollinger <John.Bollinger@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nan Liu
2012-Jun-14 16:50 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 9:44 AM, jcbollinger <John.Bollinger@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.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 > 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.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 > /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.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: client: puppet agent -t --server sub-master --ca_server master sub-master: puppet agent -t --server sub-master --ca_server master Thanks, Nan -- 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.
Scott Merrill
2012-Jun-14 17:12 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu <nan@puppetlabs.com> wrote:> On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote: >> 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.This sounds like it may be the piece I''ve been missing. On the PuppetCA, I have the following in /etc/httpd/conf.d/puppet.conf: SSLCertificateFile /var/lib/puppet/ssl/certs/top-level-master.domain.pem SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/top-level-master.domain.pem SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem On my subordinate masters, I have: SSLCertificateFile /var/lib/puppet/ssl/certs/subordinate-master.pem SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/subordinate-master.pem SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem On the subordinate masters, the ca.pem referenced in the SSLCertificateChainFile and SSLCACertificateFile is the same as the top-level master''s SSLCertificateChainFile. I copied ca_crt.pem from the top-level master to the subordinate master, and updated the SSLCACertificateFile to point to it. The node still fails with the same error message. Perhaps I''m not fully understanding you. Do I need each subordinate master to use the same public _and_ private key as the CA?>> 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: > > client: > puppet agent -t --server sub-master --ca_server masterThis is essentially the test I''ve been performing using /etc/hosts entries to point to a specific subordinate master. Using an explicit "--server" argument does not produce different results on the node: it fails.> sub-master: > puppet agent -t --server sub-master --ca_server masterI had not tried this test. Doing so fails in the same way that the client fails. Thanks, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nan Liu
2012-Jun-14 17:34 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu <nan@puppetlabs.com> wrote: >> On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote: >>> 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. > > This sounds like it may be the piece I''ve been missing. > > On the PuppetCA, I have the following in /etc/httpd/conf.d/puppet.conf: > SSLCertificateFile /var/lib/puppet/ssl/certs/top-level-master.domain.pem > SSLCertificateKeyFile > /var/lib/puppet/ssl/private_keys/top-level-master.domain.pem > SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem > SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pemShouldn''t the last line also be? /var/lib/puppet/ssl/certs/ca.pem> On my subordinate masters, I have: > SSLCertificateFile /var/lib/puppet/ssl/certs/subordinate-master.pem > SSLCertificateKeyFile > /var/lib/puppet/ssl/private_keys/subordinate-master.pem > SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem > SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem > > On the subordinate masters, the ca.pem referenced in the > SSLCertificateChainFile and SSLCACertificateFile is the same as the > top-level master''s SSLCertificateChainFile. > > I copied ca_crt.pem from the top-level master to the subordinate > master, and updated the SSLCACertificateFile to point to it. The node > still fails with the same error message. > > Perhaps I''m not fully understanding you. Do I need each subordinate > master to use the same public _and_ private key as the CA? > >>> 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: >> >> client: >> puppet agent -t --server sub-master --ca_server master > > This is essentially the test I''ve been performing using /etc/hosts > entries to point to a specific subordinate master. Using an explicit > "--server" argument does not produce different results on the node: it > fails. > >> sub-master: >> puppet agent -t --server sub-master --ca_server master > > I had not tried this test. Doing so fails in the same way that the client fails.Yeah, so it confirms so far they are only valid client certs. What''s the result of the following command on sub-master and master? openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/ca.pem What''s the output of the following on the submaster? openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/subordinate-master.pem Nan -- 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.
Scott Merrill
2012-Jun-14 17:55 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu <nan@puppetlabs.com> wrote:> On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill <skippy@skippy.net> wrote: >> On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu <nan@puppetlabs.com> wrote: >>> On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote: >>>> 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. >> >> This sounds like it may be the piece I''ve been missing. >> >> On the PuppetCA, I have the following in /etc/httpd/conf.d/puppet.conf: >> SSLCertificateFile /var/lib/puppet/ssl/certs/top-level-master.domain.pem >> SSLCertificateKeyFile >> /var/lib/puppet/ssl/private_keys/top-level-master.domain.pem >> SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem >> SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem > > Shouldn''t the last line also be? > /var/lib/puppet/ssl/certs/ca.pemYou''re asking me? I''m the one looking for help! ;)>>> sub-master: >>> puppet agent -t --server sub-master --ca_server master >> >> I had not tried this test. Doing so fails in the same way that the client fails. > > Yeah, so it confirms so far they are only valid client certs. > > What''s the result of the following command on sub-master and master? > openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/ca.pemThe output is the same on both the top-level and subordinate master: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Puppet CA: top-level-master.domain Validity Not Before: May 15 18:40:44 2012 GMT Not After : May 15 18:40:44 2017 GMT Subject: CN=Puppet CA: nlvmjt036.nwideweb.net Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) <-snip-> X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE Netscape Comment: Puppet Ruby/OpenSSL Internal Certificate X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: F6:65:DC:F3:D7:A6:7F:C3:4C:BC:C3:72:A3:39:E3:4D:AA:F9:46:1D <-snip->> What''s the output of the following on the submaster? > openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/subordinate-master.pemCertificate: Data: Version: 3 (0x2) Serial Number: 9 (0x9) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Puppet CA: top-level-master.domain Validity Not Before: May 29 01:45:38 2012 GMT Not After : May 29 01:45:38 2017 GMT Subject: CN=subordinate-master-1.domain Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) <-snip-> X509v3 extensions: X509v3 Subject Alternative Name: DNS:subordinate-master-1.domain, DNS:puppetmaster.domain X509v3 Basic Constraints: critical CA:FALSE Netscape Comment: Puppet Ruby/OpenSSL Internal Certificate X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Subject Key Identifier: F6:65:DC:F3:D7:A6:7F:C3:4C:BC:C3:72:A3:39:E3:4D:AA:F9:46:1D X509v3 Extended Key Usage: critical TLS Web Server Authentication, TLS Web Client Authentication <-snip-> Thanks, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Gary Larizza
2012-Jun-14 17:58 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 12:55 PM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu <nan@puppetlabs.com> wrote: >> On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill <skippy@skippy.net> wrote: >>> On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu <nan@puppetlabs.com> wrote: >>>> On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote: >>>>> 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. >>> >>> This sounds like it may be the piece I''ve been missing. >>> >>> On the PuppetCA, I have the following in /etc/httpd/conf.d/puppet.conf: >>> SSLCertificateFile /var/lib/puppet/ssl/certs/top-level-master.domain.pem >>> SSLCertificateKeyFile >>> /var/lib/puppet/ssl/private_keys/top-level-master.domain.pem >>> SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem >>> SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem >> >> Shouldn''t the last line also be? >> /var/lib/puppet/ssl/certs/ca.pem > > You''re asking me? I''m the one looking for help! ;) > > >>>> sub-master: >>>> puppet agent -t --server sub-master --ca_server master >>> >>> I had not tried this test. Doing so fails in the same way that the client fails. >> >> Yeah, so it confirms so far they are only valid client certs. >> >> What''s the result of the following command on sub-master and master? >> openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/ca.pem > > The output is the same on both the top-level and subordinate master: > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: CN=Puppet CA: top-level-master.domain > Validity > Not Before: May 15 18:40:44 2012 GMT > Not After : May 15 18:40:44 2017 GMT > Subject: CN=Puppet CA: nlvmjt036.nwideweb.net > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (4096 bit) > <-snip-> > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:TRUE > Netscape Comment: > Puppet Ruby/OpenSSL Internal Certificate > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > X509v3 Subject Key Identifier: > F6:65:DC:F3:D7:A6:7F:C3:4C:BC:C3:72:A3:39:E3:4D:AA:F9:46:1D > <-snip-> > >> What''s the output of the following on the submaster? >> openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/subordinate-master.pem > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 9 (0x9) > Signature Algorithm: sha1WithRSAEncryption > Issuer: CN=Puppet CA: top-level-master.domain > Validity > Not Before: May 29 01:45:38 2012 GMT > Not After : May 29 01:45:38 2017 GMT > Subject: CN=subordinate-master-1.domain > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (4096 bit) > <-snip-> > X509v3 extensions: > X509v3 Subject Alternative Name: > DNS:subordinate-master-1.domain, DNS:puppetmaster.domain > X509v3 Basic Constraints: critical > CA:FALSE > Netscape Comment: > Puppet Ruby/OpenSSL Internal Certificate > X509v3 Key Usage: critical > Digital Signature, Key Encipherment > X509v3 Subject Key Identifier: > F6:65:DC:F3:D7:A6:7F:C3:4C:BC:C3:72:A3:39:E3:4D:AA:F9:46:1D > X509v3 Extended Key Usage: critical > TLS Web Server Authentication, TLS Web Client Authentication > <-snip-> > > Thanks, > 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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >Please DO NOT take this as RTFM, but have you checked out the docs that we recommend for the process here --> http://docs.puppetlabs.com/guides/scaling_multiple_masters.html If you''re using them and there are things going wrong, PLEASE let us know what steps have fallen through so we can get that cleared up ASAP! If you''ve not seen the docs, you might want to check the process we suggested and see if there''s something you did that differs. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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.
Scott Merrill
2012-Jun-14 18:18 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 1:58 PM, Gary Larizza <gary@puppetlabs.com> wrote:> Please DO NOT take this as RTFM, but have you checked out the docs > that we recommend for the process here --> > http://docs.puppetlabs.com/guides/scaling_multiple_masters.html If > you''re using them and there are things going wrong, PLEASE let us know > what steps have fallen through so we can get that cleared up ASAP! If > you''ve not seen the docs, you might want to check the process we > suggested and see if there''s something you did that differs.I had looked at those instructions. Variances between what''s described there and what I did: * Configure CA Delegation and Get a Certificate - I did not delete the /var/lib/puppet/ssl directory on my subordinate masters before starting. - I configured my subordinate master''s puppet.conf files with the line "dns_alt_names = ....". As such, I excluded this option from the first `puppet agent` invocation for each subordinate master. - when signing the subordinate master''s certificates on the CA, I had to supply the "--allow-dns-alt-names" argument to the `puppet cert` command. * Distribute the Agent Load - I am using a hardware load balancer to spread the load across four servers (two each in two different data centers). I am using Passenger for my top-level and subordinate Puppet Masters. The proper configuration of the /etc/httpd/conf.d/puppet.conf file for subordinate master SSL configuration is not covered in the document you linked. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nan Liu
2012-Jun-14 19:13 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 10:55 AM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu <nan@puppetlabs.com> wrote: >> On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill <skippy@skippy.net> wrote: >>> On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu <nan@puppetlabs.com> wrote: >>>> On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill <skippy@skippy.net> wrote: >>>>> 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. >>> >>> This sounds like it may be the piece I''ve been missing. >>> >>> On the PuppetCA, I have the following in /etc/httpd/conf.d/puppet.conf: >>> SSLCertificateFile /var/lib/puppet/ssl/certs/top-level-master.domain.pem >>> SSLCertificateKeyFile >>> /var/lib/puppet/ssl/private_keys/top-level-master.domain.pem >>> SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem >>> SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem >> >> Shouldn''t the last line also be? >> /var/lib/puppet/ssl/certs/ca.pem > > You''re asking me? I''m the one looking for help! ;) > > >>>> sub-master: >>>> puppet agent -t --server sub-master --ca_server master >>> >>> I had not tried this test. Doing so fails in the same way that the client fails. >> >> Yeah, so it confirms so far they are only valid client certs. >> >> What''s the result of the following command on sub-master and master? >> openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/ca.pem > > The output is the same on both the top-level and subordinate master: > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: CN=Puppet CA: top-level-master.domain > Validity > Not Before: May 15 18:40:44 2012 GMT > Not After : May 15 18:40:44 2017 GMT > Subject: CN=Puppet CA: nlvmjt036.nwideweb.net > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (4096 bit) > <-snip-> > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:TRUE > Netscape Comment: > Puppet Ruby/OpenSSL Internal Certificate > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > X509v3 Subject Key Identifier: > F6:65:DC:F3:D7:A6:7F:C3:4C:BC:C3:72:A3:39:E3:4D:AA:F9:46:1D > <-snip->So normally for self signed CA the issuer and subject is the same. In this case you are issuing the certs via: CN=Puppet CA: top-level-master.domain However you are asking the system to verify against a CA cert that presents the subject as: CN=Puppet CA: nlvmjt036.nwideweb.net So you can you locate your CA cert with the subject? Subject: CN=Puppet CA: top-level-master.domain This is the CA.pem file that should be used. Nan -- 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.
Scott Merrill
2012-Jun-14 19:30 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 3:13 PM, Nan Liu <nan@puppetlabs.com> wrote:> So normally for self signed CA the issuer and subject is the same. In > this case you are issuing the certs via: > CN=Puppet CA: top-level-master.domain > > However you are asking the system to verify against a CA cert that > presents the subject as: > CN=Puppet CA: nlvmjt036.nwideweb.netWell that''s what I get for trying to sanitize the output before posting to the list. nlvmjt036 is the name of my top-level master.> So you can you locate your CA cert with the subject? > Subject: CN=Puppet CA: top-level-master.domainOn my top-level master: # diff -s /var/lib/puppet/ssl/ca/ca_crt.pem /var/lib/puppet/ssl/certs/ca.pem Files /var/lib/puppet/ssl/ca/ca_crt.pem and /var/lib/puppet/ssl/certs/ca.pem are identical As mentioned previously, the top-level master''s /var/lib/puppet/ssl/certs/ca.pem file is identical to the subordinate master''s /var/lib/puppet/ssl/certs/ca.pem file. Thanks, 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nan Liu
2012-Jun-14 21:13 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 12:30 PM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 3:13 PM, Nan Liu <nan@puppetlabs.com> wrote: >> So normally for self signed CA the issuer and subject is the same. In >> this case you are issuing the certs via: >> CN=Puppet CA: top-level-master.domain >> >> However you are asking the system to verify against a CA cert that >> presents the subject as: >> CN=Puppet CA: nlvmjt036.nwideweb.net > > Well that''s what I get for trying to sanitize the output before > posting to the list. nlvmjt036 is the name of my top-level master. > >> So you can you locate your CA cert with the subject? >> Subject: CN=Puppet CA: top-level-master.domain > > On my top-level master: > # diff -s /var/lib/puppet/ssl/ca/ca_crt.pem /var/lib/puppet/ssl/certs/ca.pem > Files /var/lib/puppet/ssl/ca/ca_crt.pem and > /var/lib/puppet/ssl/certs/ca.pem are identical > > As mentioned previously, the top-level master''s > /var/lib/puppet/ssl/certs/ca.pem file is identical to the subordinate > master''s /var/lib/puppet/ssl/certs/ca.pem file.Ok, that should be correct. The minor things I can think of is to verify CA.pem file permission and verify agent cert issuer. 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. Thanks, Nan -- 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.
Scott Merrill
2012-Jun-15 02:12 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu <nan@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Gary Larizza
2012-Jun-15 02:44 UTC
Re: [Puppet Users] Re: "Could not prepare for execution: The certificate retrieved from the master does not match the agent''s private key."
On Thu, Jun 14, 2012 at 9:12 PM, Scott Merrill <skippy@skippy.net> wrote:> On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu <nan@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, > ScottThat''s awesome to hear, Scott :) I''m glad you were able to get it setup!> > -- > 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. >-- Gary Larizza Professional Services Engineer Puppet Labs -- 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.