Issue #3360 has been updated by Luke Kanies.
I'm of mixed minds about this, but to provide background: The reason for this change was that this fixes one of the biggest usability problems in Puppet. People *constantly* will replace a host's certs but not remove the server-side cert, thus causing the client to get the old cert. Even adding code that warns the user when this is the case hadn't fixed it. As to how big of a security hole this is, in cold reality of course it isn't one because we've always expected users to know what they're doing when signing. However, I can see how in practice it can appear like one, because people might not see the consequences of signing a new certificate request. Given this compromise between the usability of new users (who, regardless of what we tell them, *constantly* remove certs on the client but not on the server) and the potential for problems resulting from this ease of certificate replacement, what do people think the right behaviour should be? Should the client just entirely fail when uploading a CSR for which the server already has a cert? If not, what else? ---------------------------------------- Bug #3360: puppetca silently overwrites existing certificates http://projects.reductivelabs.com/issues/3360 Author: Claus Divossen Status: Needs design decision Priority: Normal Assigned to: Luke Kanies Category: SSL Target version: 0.25.5 Affected version: 0.25.4 Keywords: puppetca autosigning signed certificate Branch: The puppetca accepts CSRs for CNs/nodenames that already have a signed certificate, and signing the new certificates will overwrite the old certs without warning or further validation. This seems to be introduced with the work on Bug #2890. The puppetca does not care about already exisiting signed certificates anymore. This is especially dangerous in combination with autosigning: When autosigning is active, any client can pretend to be another node as long as the desired node name matches the autosigning pattern(s). In consequence, autosigning completely disables the authorization process for matching node names. If there are node specific secrets distributed with puppet, an attacker can simply pretend to be another node with the "puppetd --fqdn" option and he will get the other node's secrets without any questions asked. The default behaviour should be to reject new CSRs for a node that already has a signed cert, especially with autosigning. When puppetca is run manually, a warning might be sufficient. -- 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://reductivelabs.com/redmine/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.
