Issue #5241 has been updated by Josh Cooper.
Puppet::Network::HttpPool#cert_setup doesn't configure its SSL context if
either the Puppet[:hostcert] or Puppet[:localcacert] files do not exist.
<pre>
# Just no-op if we don't have certs.
return false unless FileTest.exist?(Puppet[:hostcert]) and
FileTest.exist?(Puppet[:localcacert])
</pre>
This is wrong. If Puppet[:localcacert] exists, we should always use it, set
the SSL_VERIFY_PEER option, and the X509 store, regardless of whether the
agent's Puppet[:hostcert] exists or not. Doing so, will ensure that the agent
authenticates the master, even though the agent may not yet have a certificate.
For example, when an agent submits its CSR and downloads its issued certificate.
We should also add a configurable setting that will forbid the agent from
connecting if Puppet[:localcacert] doesn't exist. This way agents can be
deployed with the CA cert out-of-band and be assured that the agents will not
accidentally download the CA cert. See
[https://groups.google.com/group/puppet-users/browse_thread/thread/77cccf85e643a629/b058eaf258b949cb#b058eaf258b949cb](https://groups.google.com/group/puppet-users/browse_thread/thread/77cccf85e643a629/b058eaf258b949cb#b058eaf258b949cb)
----------------------------------------
Bug #5241: puppetd ignores local ca.pem when connecting to master for the first
time
https://projects.puppetlabs.com/issues/5241
Author: Tal Y.
Status: Accepted
Priority: High
Assignee:
Category: SSL
Target version: 2.6.x
Affected Puppet version: 2.6.2
Keywords:
Branch:
Hi,
I have a clean machine, with only puppet.conf configured (using --genconfig)
and /etc/puppet/ssl/certs/ca.pem. I now run for the first time puppetd and
connect to a server that has a *different* CA.
I believe the expected behavior should be that puppetd will abort the
connection because it connects to an unauthorized server. Instead, puppetd
continues to communicate with the unauthorized master and generates a new
certificate request.
Unless I'm mistaken, this scenario could lead to a security breach: if an
attacker gains control over the DNS, it can redirect new machines to its own
malicious master. The master will make the node install a rootkit for example.
Afterwards the attacker will redirect the DNS back to the original master. The
node will then retrieve from the original (unsuspecting) master sensitive
information, information that now the attacker can access.
I'm running puppet version 2.6.2.
Thanks,
Tal
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
