I'm setting up a puppetmaster (2.7.6) in ec2 via gems (on rhel6) and I'm running into problems with the cert names and getting the master able to talk to itself.

my puppet.conf looks like this:

  logdir = /var/log/puppet
  rundir = /var/run/puppet
  vardir = /var/lib/puppet
  ssldir = $vardir/ssl
  pluginsync = true
  environment = production
  report = true
  certname = master

When I start the puppetmaster process the ssl directory looks like:


I have an /etc/hosts entry on the box to point the 'puppet' hostname to localhost so that I don't have to change the 'server' option.

When I run the agent I get the following:

# puppet agent --test
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Server hostname 'puppet' did not match server certificate; expected master
err: /File[/var/lib/puppet/lib]: Could not evaluate: Server hostname 'puppet' did not match server certificate; expected master Could not retrieve file metadata for puppet://puppet/plugins: Server hostname 'puppet' did not match server certificate; expected master
err: Could not retrieve catalog from remote server: Server hostname 'puppet' did not match server certificate; expected master
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: Server hostname 'puppet' did not match server certificate; expected master

If I specify the certname as the server (with corresponding hosts entry) I get:

# puppet agent --test --server master 
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://master/plugins
info: Caching catalog for master
info: Applying configuration version '1321805956'
notice: Finished catalog run in 0.05 seconds

Which is success of a sort, that source error will bite me later when I'm applying manifests. I've tried a couple of other variations with using the ec2 private hostname and gotten mixed results.

I'd like to avoid setting server = 'x' and use dns/hosts to control what 'puppet' resolves to in order to decide which server (plays easier with availability zones, etc)

3 Answers 3


So after some investigation I figured this one out. Puppet 2.7.6 doesn't set subjectAltNames on the server certificate when it generates that cert for the master (it really doesn't know that it's a master at any point).

There are two ways to correct this:

1. manually generate the certifcate for the master

puppet ca generate --dns_alt_names puppet [master-name/uuid/string/etc]

2. set dns_alt_names in puppet.conf

add dns_alt_names = puppet to the master (and the master only) before you run puppet master or puppet (causing the certs to be generated)

Now with an /etc/hosts or dns entry connecting to 'puppet' will work just fine.

The other error related to plugins is a bug about having pluginsync enabled but no plugins available to sync.

  • Ahh it's a bug... Small amount of vindication! projects.puppetlabs.com/issues/10739
    – Stick
    Nov 30, 2011 at 22:37
  • Thank you! You saved me heaps of time (apparently this bug still exists as of 3.1.0 on CentOS 5 -- I'll have to figure out how to reopen the bug on PuppetLabs' bugtracker) Feb 26, 2013 at 13:27
certname = master

You have the certname set as master. For the way you are setting it up, either get it working with puppet, or use the host file to set the ip address of master instead of puppet.

You may also want to use a FQDN such as master.example.com or puppet.example.com so you can use dns entries without requiring search domain entries.

  • so setting certname = puppet allows it to work with the hosts entry but still generates that 'could not evaluate' error whenever pluginsync is turned on. Last puppetmaster I build not in ec2 didn't have this problem the default certname was fine and all that was needed was dns or hosts for host resolution.
    – Stick
    Nov 20, 2011 at 18:59

One tip for using puppet in EC2 is to assign an ElasticIP to your puppetmaster, and then create a DNS entry for the ElasticIP CNAME and not an A record for the IP.

AWS DNS servers vary their response based on if the query came from within the same EC2 region, or exterior. If the CNAME request comes from within a EC2 region, the AWS DNS servers will respond with the internal IP of the CNAME.

You should use the CNAME in DNS so that when EC2 puppet clients query the AWS DNS servers for the IP of the Puppetmaster, they will receive a response that directs them to the internal IP of the puppetmaster, and not the external IP.

  • Sound advice but doesn't address the ability for the master to talk to itself (a prerequisite to managing any external clients).
    – Stick
    Nov 21, 2011 at 21:18
  • True, and good point. I generally add a standalone puppet file to my rc.local on my ec2 puppetmaster that adds a /etc/hosts entry for itself, and restarts apache upon boot: resources { host: purge => true } host { "localhost.localdomain": host_aliases => 'localhost', ip => '', } host { $fqdn: host_aliases => $hostname, ip => $ipaddress_eth0, notify => Service['apache2'], } service { 'apache2': }
    – robbyt
    Nov 28, 2011 at 23:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .