Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
err: Could not call sign: Could not find certificate request for

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 '' 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
+          // 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.

share|improve this question
you can check your daemon.log for puppet-master records – Art Shayderov Feb 15 '11 at 20:55
up vote 1 down vote accepted

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 If it's there and needs signing, you can point puppetca at it directly by specifying puppetca --ssldir=/path/to/ssldir --sign; if it's NOT there, the client's CSR upload might have silently failed. An easy (and secure) workaround is to use puppetca --generate 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 '*' into autosign.conf on the puppetmaster's $confdir.

share|improve this answer
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 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
share|improve this answer
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

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

share|improve this answer
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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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