Home / server / Questions / 235513
Accepted
mrisher
Asked: 2011-02-15 16:43:49 +0800 CST

puppetca never returns anything

  • 772

Hi: I'm trying to configure Puppet on Ubuntu, and strangely I am never able to generate a certificate because my server never shows any pending certificate requests.

Put differently, on the server I am running puppetmasterd and on the client I am able to connect to the server, but the client continues printing

notice: Did not receive certificate
warning: peer certificate won't be verified in this SSL session

and yet the server never sees the request

mrisher@lab2$ puppetca --list                        
[nothing shows up]
mrisher@lab2$ puppetca --sign clientname.domain.com
clientname.domain.com
err: Could not call sign: Could not find certificate request for clientname.domain.com

Edit: There was a suggestion that autosign was happening, but that does not seem to be it. There is no autosign.conf file, and when I run puppetmasterd --no-daemonize -d -v I receive the following output: info: Could not find certificate for 'clientname.domain.com' every time the client says notice: Did not receive certificate

I checked the certs on the server and there don't seem to be any:

mrisher@lab2:~$ puppetca --list --all
mrisher@lab2:~$ sudo puppetca --list --all
+ lab2.domain.com          // this is the server (master)
mrisher@lab2:~$ sudo puppetca --list      
[blank line]
mrisher@lab2:~$

Note: This is mostly running the default install from Ubuntu, if that gives any leads.

Thanks for any help out there.

EDIT It appears this was due to inconsistently running puppetd as different users. For reasons I don't really understand for a daemon, puppet stores some of its settings -- including the certificates -- in ~/.puppet rather than a central directory like /var/lib/puppet, and thus it matters if you're testing as yourself versus sudo.

puppet configuration

4 Answers

  1. This is actually the kind of behavior you'll see if autosigning is enabled. You can look at the contents of /etc/puppet/autosign.conf to see exactly which domains this is enabled for. For example, suppose that file contained the following:

    *.example.com
192.168.0.0/24

    This would mean that any certificates that come from a hostname under the example.com tree, or from 192.168.0.0/24 address block, would be signed by puppetca without any admin interaction.

    You can view all of the certificates, signed or not, by issuing the command 

    /usr/sbin/puppetca --list --all
    • 1

  2. Try ruling out a puppet master certname mismatch.

    On the agent node:

    $ sudo puppetd --configprint server

    On the master: 

    $ sudo puppetca --print lab2.domain.com

    ...and look for these lines in the output it dumps:

    ...
Subject: CN={A hostname}
...
X509v3 Subject Alternative Name: 
DNS:{a hostname}, DNS:{another hostname}, {etc.}

    If the hostname the agent is using to contact the master IS a valid hostname for the master but ISN'T in the "subject common name" (certname) or "subject alternative name" (certdnsnames) fields in the master's SSL certificate, you'll be in a world of pain.

    (If that turns out to be the problem, either change puppet.conf on the agent to point to a working certname or certdnsname for the puppet master, or stop the puppet master, edit the puppet.conf to have the certname and certdnsnames you want, blow away its ssldir (puppetmaster --configprint ssldir), and restart the master.)

    • 1
  3. Best Answer

    Did your certificate request ever make it to the server? (Use the value of puppetmasterd --configprint ssldir where I've written $ssldir here)

    Under $ssldir/ca there should be a directory structure like this:

       private/
   requests/
   serial
   signed/

    And under requests, if your client's request actually made it up, you should see a file named clientname.domain.com.pem. If it's there and needs signing, you can point puppetca at it directly by specifying puppetca --ssldir=/path/to/ssldir --sign clientname.domain.com; if it's NOT there, the client's CSR upload might have silently failed. An easy (and secure) workaround is to use puppetca --generate clientname.domain.com on your puppetmaster to make a keypair and signed certificate for the clients. An easy and insecure workaround is to turn on autosigning for your domain by dropping '*.domain.com' into autosign.conf on the puppetmaster's $confdir.

    • 1

  4. I wanted to chime in to explain something I found: Let's say it was halfway working (where the client could contact the puppet-master, but now the certificate requests no longer show up). In my case, I had it halfway working, but then, I couldn't even SSH from the client to the puppet-master. Odd. In this case, I had to go through those same ssl directories (above) on the client site to remove the client and puppet-master certificates, and clean out the ca files for the puppet-master. On the puppet-master I had to do the mirror action of removing traces of the client certificate from all directories, AND the client listing in the /var/lib/puppet/ssl/ca/inventory.txt file.

    After doing this and rebooting both, I could then see the request. The issue was that the puppet-master had once had a valid cert listing for the client in the inventory.txt file in the /var/lib/puppet/ssl/ca directory, but I had cleaned out or deleted the actual certificate. My syslog on the puppet-master showed: "Certificate not found for host...", meaning it knew one was in inventory, but the actual certificate was on metaphorical 'back order' or just plain missing.

    So, clean the old certificates out for the ca, and puppet-master on the client side. Then remove the cert and cert listing in the inventory.txt, and this should work.

    • 1