Issue #15561 has been updated by Matt Wise.
Jeff, This should impact anybody trying to upgrade from Puppet 2.7.14 to a newer version who has created their own SSL certificate for the Puppet servers, rather than relying on the internal mechanism to dynamically generate a 'generic' cert. A specific example of our failure message on the Puppet clients: Error: Could not send report: Certname "/c=us/st=california/l=san francisco/o=nextdoor.com/ou=operationsnextdoor.com puppet master root ca/[email protected]" must not contain unprintable or non-ASCII characters Here is the actual header information for our puppet server CA file: Certificate: Data: Version: 3 (0x2) Serial Number: 16725167120499163912 (0xe81bbae1e2654308) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Francisco, O=Nextdoor.com, OU=Operations, CN=Nextdoor.com Puppet Master Root CA/[email protected] Validity Not Before: Nov 15 21:01:14 2011 GMT Not After : xxx Subject: C=US, ST=California, L=San Francisco, O=Nextdoor.com, OU=Operations, CN=Nextdoor.com Puppet Master Root CA/[email protected] and here's a copy of the header from an individual puppet server (we have several, that all generate their key from the single CA that we've internally created) Certificate: Data: Version: 3 (0x2) Serial Number: 18287165440 (0x442000000) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Francisco, O=Nextdoor.com, OU=Operations, CN=Nextdoor.com Puppet Master Root CA/[email protected] Validity Not Before: Dec 4 17:10:17 2012 GMT Not After : xxx Subject: CN=test-puppet-uswest2-i-12345678.xyz.nextdoor.com Subject Public Key Info: We've done really nothing unique here ... we created the SSL CA and filled out the information appropriately in a way that most certs do, including email addresses. The CN just happens to include a / in it because thats how the openssl command created it. The only option for us at this point would be to systematically wipe out our entire Puppet CA, regenerate it, and then re-generate and re-sign Puppet certs on every single system in our infrastructure. This is a huge task for us. ---------------------------------------- Bug #15561: Fix for CVE-2012-3867 is too restrictive https://projects.puppetlabs.com/issues/15561#change-78255 Author: Dustin Mitchell Status: Accepted Priority: Urgent Assignee: Category: SSL Target version: 2.7.x Affected Puppet version: 2.7.18 Keywords: certificate Branch: https://github.com/puppetlabs/puppet/pull/1101 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/[email protected]/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 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.
