Issue #15561 has been updated by Jeff McCune.
On Sun, Mar 31, 2013 at 10:48 AM, wrote: > Issue #15561 has been updated by Dustin Mitchell. > > > @Jeff, how do you think validation of such HTTPS servers should be handled? > Is there a specific reason you need the server certificate signed by a CA other than the Puppet CA used with all of the other certificates? I'm trying to understand the use case a bit more. Looking at the code, our http report processor uses the Puppet http client classes, which means that only the Puppet CA's will be trusted. The Puppet HTTP classes don't trust the public root authorities by default. Here's how I recommend working around this, in order of preference. Either; use a server certificate issued by the Puppet CA if possible, or copy the [http]( https://github.com/puppetlabs/puppet/blob/master/lib/puppet/reports/http.rb#L19) report processor and replace Puppet ::Network::HttpPool with Net::HTTP or something equivalent that trusts the public CA's. I don't think we should fix this in Puppet core because it really seems like this should be a custom report processor if the Puppet CA is not being used to issue the report server certificate. -Jeff ---------------------------------------- Bug #15561: Fix for CVE-2012-3867 is too restrictive https://projects.puppetlabs.com/issues/15561#change-87820 * Author: Dustin Mitchell * Status: Merged - Pending Release * Priority: Urgent * Assignee: * Category: SSL * Target version: 3.2.0 * Affected Puppet version: 2.7.18 * Keywords: certificate * Branch: https://github.com/puppetlabs/puppet/pull/1556 ---------------------------------------- The fix for CVE-2012-3867 involves checking certificate subjects for "weird" characters. From my read of the CVE entry, this is to filter out characters that would cause the name to display in a manner visually indistinguishable from a valid hostname. However, the check is too restrictive: Could not retrieve catalog from remote server: Certname "puppetagain base ca/emailaddress=rele...@mozilla.com/ou=release engineering/o=mozilla, inc." must not contain unprintable or non-ASCII characters In particular, / is a very common character in subjects, and should be allowed. Puppet is seeing this subject on my base CA - I'm using certificate chaining. The fix is one character, so I haven't included a patch, but I'm happy to make a pull req if necessary. Another fix would be to only verify certificate subjects for the leaf certificate, and not any of the certs in its signing chain, but that seems less secure. It's also worth noting that the regex is overly broad, since it downcases the string, then accepts A-Z among other characters. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
