I'm trying to setup puppet for the first time.

I've ensured port 8140 and 22 are open using ufw.

Both the server and agent are running. Before starting the agent I edited /etc/puppet/puppet.conf by adding:


I also did the above for /etc/puppetlabs/puppet/puppet.conf, not sure if I should have both, when I run puppet --version, I get back 4.10.

Agent server's IP is set to that of master-server.

I run puppet cert list expecting to see a request from the agent, which I pointed at my laptop, but I don't see any requests.

I'm not sure what to do next to figure out why the agent doesn't connect.


I ran puppet agent --test which returned:

Info: Creating a new SSL key for ip-172-00-00-00.us-west-2.compute.internal
Error: Could not request certificate: Failed to open TCP connection to puppet:8140 (getaddrinfo: Name or service not known)
Exiting; failed to retrieve certificate and waitforcert is disabled

I've ensured my laptop is in the DMZ and can successfully ping it from the agent server.


@DylanKnoll pointed out that the default value for server was puppet, so it may not accept ip addresses. I found some more documentation on what puppet aliased to here. I then removed the configuration above and added this line to /etc/hosts: puppet

After this change the error I received changed. So they seem to be making a connection. I'm still using an IP address so maybe I will need a domain name to get a proper ssl connection (?)

Error message:

Error: Could not request certificate: The CSR retrieved from the master does not match the agent's public key.
CSR fingerprint: BF:43:71:72:86:45:76:E9:34:20:24:71:B6:0C:88:25:3A:67:5E:C4:84:D5:E0:22:C9:1A:9E:FD:98:C1:0D:3C
CSR public key: Public-Key: (4096 bit)
    # lines removed
Exponent: 65537 (0x10001)

Agent public key: Public-Key: (4096 bit)
    # lines removed
Exponent: 65537 (0x10001)

To fix this, remove the CSR from both the master and the agent and then start a puppet run, which will automatically regenerate a CSR.
On the master:
  puppet cert clean ip-172-31-27-12.us-west-2.compute.internal
On the agent:
  1a. On most platforms: find /home/ubuntu/.puppetlabs/etc/puppet/ssl -name ip-172-31-27-12.us-west-2.compute.internal.pem -delete
  1b. On Windows: del "\home\ubuntu\.puppetlabs\etc\puppet\ssl\certs\ip-172-31-27-12.us-west-2.compute.internal.pem" /f
  2. puppet agent -t
  • 1
    "Error: Could not request certificate: Failed to open TCP connection to puppet:8140 (getaddrinfo: Name or service not known)" The name puppet is not resolvable by your laptop. I assume it should be attempting to contact the puppet master at a different, fully qualifed address, specifically one that matches the subject name on the puppet master certificate. – Dylan Knoll Apr 25 '17 at 1:55
  • @DylanKnoll I haven't manually made a certificate, is it generated automatically? I assumed having the IP address of the puppet-master would be enough. – Philip Kirkbride Apr 25 '17 at 1:58
  • I'm not even a puppet user but it seems that it is automatically generated. The documentation for the 'server' option in puppet.conf, that I can see, only ever refers to using a name, but an IP address. The default value for 'server' is 'puppet' so the fact it's still attempting to connect to 'puppet' suggests that it's either not using the intended config file or your config file has an invalid 'server' line. Can you attempt to use a name for 'server'? – Dylan Knoll Apr 25 '17 at 2:03
  • @DylanKnoll I assumed puppet was an alias for localhost:8140 or something like that. Given the master and agent are on two separate servers it wouldn't be possible for them to communicate without having the master IP address somewhere. – Philip Kirkbride Apr 25 '17 at 2:07
  • A name would resolve to an IP, also generally when SSL is involved you use names so you can verify the name/address used against the subject name in the cert. – Dylan Knoll Apr 25 '17 at 2:07

Did you run puppet agent --test on the agent to generate (and send) the initial cert request? That should put the agent in the certificate request list of your master.

If the agent's just complaining about not finding a cert then quitting, it may be thinking that it's already sent a request - just reset its memory as far as SSL is concerned by backing up then nuking the configured puppet SSL directory (by default, /var/lib/puppet/ssl or /etc/puppetlabs/puppet/ssl), then running puppet agent --test (with --debug and --verbose if you want to make really sure) - this run should output that it's generating a new cert request, and it should be sent to the configured master.

  • Thanks, I added the response to my question. I'm considering the possibility that my home router is blocking all incoming port requests. – Philip Kirkbride Apr 22 '17 at 12:59

The error message tells you exactly what to do. Clear the nodes SSL folder:

rm -rf /etc/puppetlabs/puppet/ssl

Note: This deletes all puppet SSL certificates, CSR, etc. So only do it on the node, not on the server.

Then, remove the CSR from the puppetmaster:

sudo /opt/puppetlabs/bin/puppet cert clean <hostname>

Afterwards, do another puppet run on the node:

sudo /opt/puppetlabs/bin/puppet agent -tv

This will generate a new CSR.

  • I deleted the ssl folder on both agent and master still kept getting the message. I'll try it again soon with the cert clean instead of deleting the ssl folder on master. Thanks – Philip Kirkbride Apr 25 '17 at 10:49
  • Using puppet cert list --all I can confirm that the master doesn't have a cert for the node when I attempted to follow the instructions in the error message. – Philip Kirkbride Apr 25 '17 at 10:54
  • Since you now deleted all SSL certs on the master, you probably have to restart it since you deleted the certificate authority. – mzhaase Apr 25 '17 at 10:57
  • Thanks was restarting every time because I read you need to re-initialize the ssl folder. I would delete it on both then restart both and then attempt the connection again. – Philip Kirkbride Apr 25 '17 at 10:59
  • 1
    Then the request is not arriving at the puppetmaster at all. Are you sure the IP in puppet.conf is correct? Are the '000' just placeholder? If not, you have to do just '0' – mzhaase Apr 25 '17 at 11:07

If you are using Azure VMs and then connecting to PuTTY then you need to open the port 8140 in Azure because all ports are by default blocked. Go to VM networking option and add allow rules for port 8140(as puppet works on port 8140) Then again try connecting from new to PuTTY it will 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.