Issue #5241 has been updated by R.I. Pienaar.
Some additional behavior here that is related and not desirable. When the puppetd determines it needs to request a new cert it does not validate the authenticity of the master using ca.pem. <pre> # cd /var/lib/puppet/ssl/certs # cp /some/other/ca.pem ca.pem && hostname some.other.name && puppetd --test info: Creating a new SSL key for some.other.name warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for some.other.name info: Certificate Request fingerprint (md5): FA:40:44:09:BD:51:7E:64:25:7D:07:16:D3:33:6C:9C warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session Exiting; no certificate found and waitforcert is disabled </pre> Here the machine got a different ca.pem Later if I sign the cert on the master the client will fetch and cache the signed cert it will only then validate the CA and refuse to do a run. I'd really rather the client doesnt send a csr or cache certs from machines it cant validate the CA of. As for the original request, if there is a ca.pem it should be trusted at all times basically. Similarly if there is a signed cert for fqdn and the ca.pem is missing that should be a problem, the puppetd should not do a run and cache the ca.pem it should bail out since it cant validate that CA ---------------------------------------- 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: Investigating Priority: High Assignee: Nigel Kersten Category: SSL Target version: 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.
