FAQ
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.

Search Discussions

  • Felix Frank at Jun 13, 2012 at 11:26 am
    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 at Jun 13, 2012 at 1:42 pm

    On Wed, Jun 13, 2012 at 7:26 AM, Felix Frank 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 at Jun 14, 2012 at 1:44 pm

    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 at Jun 14, 2012 at 4:27 pm

    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
    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 at Jun 14, 2012 at 4:51 pm

    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
    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 at Jun 14, 2012 at 5:12 pm

    On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill 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 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.

    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 at Jun 14, 2012 at 5:34 pm

    On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill 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
    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 at Jun 14, 2012 at 5:55 pm

    On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill 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.
  • Gary Larizza at Jun 14, 2012 at 5:58 pm

    On Thu, Jun 14, 2012 at 12:55 PM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill 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 at Jun 14, 2012 at 6:18 pm

    On Thu, Jun 14, 2012 at 1:58 PM, Gary Larizza 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 at Jun 14, 2012 at 7:14 pm

    On Thu, Jun 14, 2012 at 10:55 AM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 1:34 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 10:12 AM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 12:50 PM, Nan Liu wrote:
    On Thu, Jun 14, 2012 at 9:27 AM, Scott Merrill 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 at Jun 14, 2012 at 7:30 pm

    On Thu, Jun 14, 2012 at 3:13 PM, Nan Liu 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.

    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 at Jun 14, 2012 at 9:13 pm

    On Thu, Jun 14, 2012 at 12:30 PM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 3:13 PM, Nan Liu 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 at Jun 15, 2012 at 2:12 am

    On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu 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 at Jun 15, 2012 at 2:44 am

    On Thu, Jun 14, 2012 at 9:12 PM, Scott Merrill wrote:
    On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu 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
    That'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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 12, '12 at 6:54p
activeJun 15, '12 at 2:44a
posts16
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase