Issue #1765 has been updated by luke.
IanTurner wrote: > Luke, > > We tried changing a systems hostname and renaming all its certificate files > accordingly, and it was able to retrieve the other host's configuration > without any problem or server intervention. Perhaps this is a configuration > issue? If you point me to the right directive I'll have a look. > > From my perspective, verifying that the certificate hostname is the same as > the facter hostname is functionally equivalent to just using the certificate > hostname, so if that's the approach then I think that's great. Our plan at > the moment is to have all information about a server's role in the > organization be derived from hostname alone, so if that can be verified it > should be adequate. If you changed a host's name but not its certificate and it retrieved the catalog for the new hostname, then you hopefully have the "node_name" setting set to 'facter' rather than the default, 'cert'. If that's not the case and this still worked, then that's not just a bug, it's difficult to understand how it could have happened. nigelk2 wrote: > If movement is made in this direction, I'd like to point out that those of us > who use Puppet to manage laptops don't use the hostname for the certificate > at all. > > We use UUIDs here that we already have to uniquely identify machiens. I can absolutely guarantee, while I'm in "charge", that you'll always be able to use UUIDs in your certificates. parimi wrote: > Are we comparing apples to apples while we talk about the complexity of > server configuration and security vs. laptops? > > Isn't it an additional overhead to map the hosts to UUIDs? It's more of a gradient than apples to apples -- some people use entirely dynamic information for servers, for things like load pools, for instance. And yes, it's additional work, but that overhead is present regardless, because the hostname is often just not consistently manageable on a laptop. ---------------------------------------- Bug #1765: Certificate hostnames are not verified http://projects.reductivelabs.com/issues/show/1765 Author: IanTurner Status: Needs design decision Priority: Normal Assigned to: Category: SSL Target version: Complexity: Hard Affected version: 0.24.6 Keywords: certificate security spoof validation authentication dns The puppetmaster only verifies the validity of the client certificate, but does not verify the associated hostname. Thus a client with a certificate signed as "publicserver" can instead claim to be "secretserver" and gain access to the latter's configuration. This certificate hostname spoofing can be a serious issue, since client configuration may include password hashes and other confidential data. The best approach to client validation is to verify that all three of the following are identical at the FQDN level: 1. The FQDN on the signed client certificate. 2. The FQDN presented by the client facter invocation. 3. The result of a reverse lookup on the connecting client IP address. Additionally, an address (A/AAAA record, not CNAME record) lookup on this FQDN should in turn yield the connecting client IP address in the query result. ---------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
