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
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]

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.

  • you can check your daemon.log for puppet-master records Feb 15 '11 at 20:55

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:


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.

  • Hi: The certificate did make it to the server; the problem seems to have been related to the user that puppetd runs as -- when I started it in test most, I was inconsistent about "sudo" and since the certificates are stored in ~/.puppet I was getting inconsistent results.
    – mrisher
    Mar 10 '11 at 6:09

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:


This would mean that any certificates that come from a hostname under the example.com tree, or from 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
  • Thank you for the suggestion. Unfortunately, there is no autosign.conf in /etc/puppet, and when I run "puppetca --list --all" either as myself or under "sudo" it shows only the master.
    – mrisher
    Feb 15 '11 at 1:23

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

  • I agree with nfagerlund and ran into exactly this behavior a few weeks ago.
    – kashani
    Feb 15 '11 at 20:08

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.