The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #15561

Fix for CVE-2012-3867 is too restrictive

Added by Dustin Mitchell almost 4 years ago. Updated about 3 years ago.

Status:ClosedStart date:07/17/2012
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:SSL
Target version:3.2.0
Affected Puppet version:2.7.18 Branch:https://github.com/puppetlabs/puppet/pull/1556
Keywords:certificate

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

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=release@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.


Related issues

Related to Puppet - Bug #18958: Puppet's built-in PKI is problematic Accepted
Related to Puppet - Bug #17879: extract cert name properly from subject DN Duplicate
Related to Puppet - Bug #3120: 'localcacert' doesn't behave as described Closed 01/27/2010
Related to Puppet - Feature #3143: Fully support multiple CAs and CA trust chains in Puppet Closed 02/03/2010
Related to Puppet - Bug #20027: Puppet ssl_client_ca_auth setting does not behave as docu... Closed
Related to Puppet - Bug #20742: unauthenticated clients unable to communicate with puppet... Closed
Related to Puppet - Bug #14852: Puppet should correctly parse CN when DN contains an emai... Closed 06/06/2012
Duplicated by Puppet - Bug #19487: Puppet thinks most external CA certs are invalid Duplicate

History

#1 Updated by Anonymous almost 4 years ago

  • Category set to SSL
  • Status changed from Unreviewed to Accepted
  • Target version set to 2.7.x
  • Affected Puppet version set to 2.7.18
  • Keywords set to certificate

#2 Updated by Wojtek B almost 4 years ago

Impact data as requested: After upgrading to 2.7.13 –> 2.7.18 (versions in debian testing) no SSL connections are possible between agents and masters.

It seems that only setups with externally signed certificates are affected. Our puppet-only sub-setup works fine.

#3 Updated by Matt Wise almost 4 years ago

This bug just bit us as well for a few hours… This is definitely a bug, its entirely normal to have ‘/’ characters in a certificate name.

#4 Updated by Nicola V over 3 years ago

Wojtek B wrote:

Impact data as requested: After upgrading to 2.7.13 –> 2.7.18 (versions in debian testing) no SSL connections are possible between agents and masters.

It seems that only setups with externally signed certificates are affected. Our puppet-only sub-setup works fine.

Hi, I’m noticing this issue on version 2.7.11 as well. This version is the one currently shipped with ubuntu 12.04.1. Anyone having this issue on 12.04?

Thanks.

#5 Updated by Dustin Mitchell over 3 years ago

Nicola, at a guess, Ubuntu backported the “security fix” for CVE-2012-3867 into 2.7.11. So you can help out by ensuring that they also backport the fix to the fix, when it’s ready :)

I was hoping this would be fixed in 2.7.19 – having to black out more than one version in my system is going to be annoying.

#6 Updated by Nicola V over 3 years ago

Dustin Mitchell wrote:

Nicola, at a guess, Ubuntu backported the “security fix” for CVE-2012-3867 into 2.7.11. So you can help out by ensuring that they also backport the fix to the fix, when it’s ready :)

I was hoping this would be fixed in 2.7.19 – having to black out more than one version in my system is going to be annoying.

Hi Dustin, I’d say this might well be the case. We have a support contract with Canonical, I’ll notify them about this issue and refer to this ticket :)

#7 Updated by Ben Jones over 3 years ago

+1 for hoping this was going to be fixed in 2.7.19. This bit us just as we were migrating to use our own CA.

#8 Updated by Dustin Mitchell over 3 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Assignee set to Dustin Mitchell
  • Branch set to https://github.com/puppetlabs/puppet/pull/1101

#9 Updated by Dustin Mitchell over 3 years ago

(bringing the convo back here from the pull req)

dpittman:

@jeffmccune is the last person I know who looked at this, but because of some horrible internal deficiencies allowing / will actually break various parts of the certificate handling. Which is kind of awful.

dustin:

They work in 2.7.17..

dpittman

They partially work in 2.7.17: you can load the certificate, but you can’t enumerate it. Which leads to some issues at times.

This bug is presently blocking me from upgrading past 2.7.17, which is disconcerting since 2.7.18 is a security-fix release. So if it’s hard to go forward and fix the /-handling problems, can we at least go back to how it was in 2.7.17?

Alternately, can you point me to some more information about the problems stemming from the /, and I’ll see if I can find a fix?

#10 Updated by Anonymous over 3 years ago

  • Status changed from In Topic Branch Pending Review to Accepted
  • Assignee deleted (Dustin Mitchell)

Here’s the update I posted to the pull request:

@daniel-pittman Thank you for the update, this saves some duplicate effort.

@battlemidget I’m going to go ahead and close this pull request and update the corresponding issue #15561. This isn’t to say that we won’t fix this issue or that we don’t consider 15561 a valid and accepted bug. We do and we will. I’m closing this with this update in an effort to get this out of limbo and make it clear that 15561 is more about fixing the core issue in the certificate indirections than it is about changing the regular expression for the CN.

On a side note, I’m really sorry this issue has sat dormant for so long. I really you appreciate taking the time to speak up and ping us about the issues that are affecting you.

Hope this helps. -Jeff

#11 Updated by adam stokes over 3 years ago

Hi,

Curious if we could get an update on this particular issues progress? I realize there are a lot of factors involved so any information you can give would be very appreciated.

Thanks Adam

#12 Updated by Matt Wise over 3 years ago

  • Priority changed from Normal to Urgent

Jeff, This bug is still sitting open and affects all versions of Puppet after 2.7.18. Here I am trying to upgrade to 3.0.1, and I find the bug still exists. This has been sitting for 5 months now. Not fixing a bug as serious as this (that is, that it blocks upgrades to any newer version of Puppet) after this long does not instill confidence for businesses that are using this tool to manage their infrastructures.

When will this be fixed? We are really not happy being so far behind on our Puppet versions, especially given the security fixes that have gone into Puppet in the last few months.

#13 Updated by Anonymous over 3 years ago

Matt Wise wrote:

Jeff, This bug is still sitting open and affects all versions of Puppet after 2.7.18. Here I am trying to upgrade to 3.0.1, and I find the bug still exists. This has been sitting for 5 months now. Not fixing a bug as serious as this (that is, that it blocks upgrades to any newer version of Puppet) after this long does not instill confidence for businesses that are using this tool to manage their infrastructures.

I’m really sorry you can’t upgrade to Puppet 3, the fact that this bug is still open really bothers me too. I wish I had a better answer for you but not much has changed since I closed the pull request.

Here’s where we’re at; Unfortunately, we can’t simply allow /’s in certificate names because doing so without also making substantial changes to the way the indirection subsystem works would re-open CVE-2012-3867 Daniel confirmed this in the pull request discussion:

To be clear, my review was “-1, this is not acceptable to merge without substantial changes”. The changes are to address, as Jeff notes, the internal assumptions in Puppet (in lib/puppet/indirector/{file,cert/,key/*}.rb) that the CN and the filename on disk match in any meaningful way. That includes making sure that, eg, “search” operations still work, etc.

This means this isn’t a matter of simply changing the regular expression. If we do change just the regular expression without also addressing the core issues in the indirector subsystem, then we’re back to a gaping security hole.

When will this be fixed? We are really not happy being so far behind on our Puppet versions, especially given the security fixes that have gone into Puppet in the last few months.

As much as I’d like to, I cannot provide you with any new information about when this will be fixed. There are no plans to make substantial changes to the indirector subsystem that I am aware of. I wish I had something better to tell you regarding this issue.

Perhaps Eric will have some ideas regarding how best to get this issue prioritized higher than it currently is, but honestly I just don’t think it’s affecting as many users as some of the other fundamental issues we’re currently wrestling with. Settings and code loading affect nearly every Puppet user for example. As far as I know this issue is primarily affecting users who have an external CA, which is a much smaller population.

Knowing that this issue is a blocker for you upgrading to Puppet 3.0 is valuable impact data. Do you have a sense of how many sites are unable to upgrade to Puppet 3 because of this issue?

Sorry I don’t have better news for you at this time…

-Jeff

#14 Updated by Matt Wise over 3 years ago

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/emailaddress=ops@nextdoor.com” 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/emailAddress=ops@nextdoor.com
    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/emailAddress=ops@nextdoor.com

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/emailAddress=ops@nextdoor.com
    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.

#15 Updated by Dustin Mitchell over 3 years ago

I’m reconsidering my desire to use certificate chainging, since puppetlabs doesn’t support it (really, SSL is barely supported at all). But I don’t think I’ll be able to get to the point of having cert names that fit this pattern.

I’ll probably end up forking puppet and building RPMs, DMGs, etc. with these and other patches included, with a big warning to be cautious of the security implications. Would that be helpful? It’s no less secure than running 2.7.17 forever!

#16 Updated by Yuri Arabadji over 3 years ago

What if you apply patch from #17879? Thanks.

#17 Updated by Anonymous over 3 years ago

Yuri Arabadji wrote:

What if you apply patch from #17879? Thanks.

I updated that ticket with more information. I don’t understand how that patch addresses this issue.

-Jeff

#18 Updated by Scott Bryant over 3 years ago

Just adding in on this, hoping this is in the right place..

Having the following issue with creating the certs using puppet.

Info: Creating a new SSL key for xxxxxx.soe.local Error: Could not request certificate: Certname “/c=—/st=somestate/l=somecity/o=someorganization/ou=someorganizationalunitxxxxxx.soe.local/emailaddress=root@xxxxxx.soe.local” must not contain unprintable or non-ASCII characters Exiting; failed to retrieve certificate and waitforcert is disabled

This is a generic base install from the 3.0.1 rpms. So no certs created anywhere. wondering if its similar.

#19 Updated by Yuri Arabadji over 3 years ago

Scott, you should try my patch and see if that helps. Both on master and agent. The problem is in CN extraction, which is very poorly coded. PL didn’t test when puppet is fed with certs from external CA.

#20 Updated by Dustin Mitchell over 3 years ago

OpenSSL requires a slash in the subject:

[root@relabs07 ssl-master]#  openssl req  -new -newkey rsa:2048 -keyout ca/ca_key.pem    -days 3650 -x509 -out ca/ca_crt.pem    -subj 'foo'
Generating a 2048 bit RSA private key
..............................................................................+++
...........................................................................................................................................................................................................................................................+++
writing new private key to 'ca/ca_key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
Subject does not start with '/'.
problems making Certificate Request

so, .. yeah. I’m working on a version of 3.0.2 with https://github.com/puppetlabs/puppet/pull/1101 patched in, since that seems the only way to make this work.

Yuri, can you explain a bit more how your patch works, and make a pull request for it, attached here?

#21 Updated by Anonymous over 3 years ago

  • Target version deleted (2.7.x)

As the 2.7.x line is winding down, I am removing the target at 2.7.x from tickets in the system. The 2.7 line should only receive fixes for major problems (crashes, for instance) or security problems.

#22 Updated by adam stokes about 3 years ago

Andrew Parker wrote:

As the 2.7.x line is winding down, I am removing the target at 2.7.x from tickets in the system. The 2.7 line should only receive fixes for major problems (crashes, for instance) or security problems.

How is this not considered a major problem? I would say from the amount of corporations using this product who are on distributions like Ubuntu LTS and even RHEL I still see this as a huge problem that should be addressed.

Please re-add the 2.7.x tag and more importantly provide a fix.

Thank you for your time Adam

#23 Updated by Dustin Mitchell about 3 years ago

Tag or not, this is unlikely to get fixed. It’s still present in 3.0.2, anyway.

#24 Updated by Nicola V about 3 years ago

adam stokes wrote:

How is this not considered a major problem? I would say from the amount of corporations using this product who are on distributions like Ubuntu LTS and even RHEL I still see this as a huge problem that should be addressed.

Please re-add the 2.7.x tag and more importantly provide a fix.

I second that. We just started the migration to Ubuntu 12.04 and our current fix consists in downgrading to the 2.6.x series during the late-command stage in the preseed. This is more of a hack then a fix.

#25 Updated by adam stokes about 3 years ago

Nicola V wrote:

adam stokes wrote:

How is this not considered a major problem? I would say from the amount of corporations using this product who are on distributions like Ubuntu LTS and even RHEL I still see this as a huge problem that should be addressed.

Please re-add the 2.7.x tag and more importantly provide a fix.

I second that. We just started the migration to Ubuntu 12.04 and our current fix consists in downgrading to the 2.6.x series during the late-command stage in the preseed. This is more of a hack then a fix.

Here is our bug report for this case if you wish to subscribe to that as well:

http://launchpad.net/bugs/1068145

#26 Updated by Nicola V about 3 years ago

adam stokes wrote:

Here is our bug report for this case if you wish to subscribe to that as well:

http://launchpad.net/bugs/1068145

Hi Adam, yes, apparently that ticket is describing the issue we have. It looks like the bug report has been opened after we requested support to Canonical (the cn of that cert is ours).

I’m kindly asking if there’s any eta for the fix, even in major version 3.x. We can plan an upgrade to 3.x but we’d like to be sure of the version containing the fix.

Thanks.

#27 Updated by Jason Hancock about 3 years ago

You can also run into this bug when using the http report processor submitting to an https reporturl where the certificate has a ‘/’ in it.

#29 Updated by Anonymous about 3 years ago

Yuri Arabadji wrote:

okay, what if you try https://github.com/puppetlabs/puppet/pull/1490 ? tnx.

Unfortunately this change does not sufficiently address the root cause of the problem, and as a result risks regression of CVE-2012-3867. Please see the comments I posted on Github for more information and next steps to proceed.

#30 Updated by Rob Hendelman about 3 years ago

This is affecting us here as well. I’m trying to setup the puppet server to submit reports to our puppet report server via apache2+passenger with ssl & I’m getting “Report processor failed: Certname ”$certname_with_slashes_in_it" must not contain unprinable or non-ascii characters.

Outside of giving up having ssl communiactions between these boxes (for submitting reports), does anyone know of a workaround? I’m using version 3.1.0-1puppetlabs1 on the puppet server & the reporting server.

#31 Updated by Dustin Mitchell about 3 years ago

The best workaround I’ve found is to just back out the patch. It’s relatively small and easy to apply, although it does mean rolling your own packages.

#32 Updated by Poul H. Sørensen about 3 years ago

We just got bit by this, when we tried to use officially signed certificates ourselves.

I think that this issue actual consists of (at least) two problems.

I have full understanding for the problems that occur due to using the certname as (part of) filename, but I think that the problems that arise from this, is important to solve (in a not too distant release).

  • problem №1:
    Puppet support for signing using own (non-puppet) certificates. This is needed when using several seperate puppet-cert servers, and moving the puppet client from one cert-server to another. I guess that there also exists other situations, where one may wan to use own certificates.
  • problem №2:
    Puppet support for IDN's (Internationalized domain names) (default value of puppetcert is FQDN).

#33 Updated by Dustin Mitchell about 3 years ago

I’m going to try to describe, overall, what a solution for No 1 would look like. Hopefully we can get this fixed.

I need to figure out whether I was incorrect in comment 20 – I think it is possible to set up a certificate without a ‘/’ character, but I may be confusing subject and DN.

#34 Updated by Poul H. Sørensen about 3 years ago

Certificates that are signed by an Certificate Authority is likely to contain a ‘/’

#35 Updated by Dustin Mitchell about 3 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch changed from https://github.com/puppetlabs/puppet/pull/1101 to https://github.com/puppetlabs/puppet/pull/1556

On some deeper inspection, there are problems with how Puppet parses the subject of certs. In particular, in trying to extract just the CN, it extracts the CN and all following text. The restrictions put in place for this CVE are fine for a CN, but are too restrictive for the whole subject.

https://github.com/puppetlabs/puppet/pull/1556 fixes the CN extraction. With this fix, my test script at https://gist.github.com/djmitche/5233972 passes.

#36 Updated by Dustin Mitchell about 3 years ago

  • Target version set to 3.2.0

Hopefully my understanding from the last few days is correct that this is targeted for 3.2.0 now.

#37 Updated by Anonymous about 3 years ago

Dustin Mitchell wrote:

Hopefully my understanding from the last few days is correct that this is targeted for 3.2.0 now.

That’s correct, we’re hoping to get this fixed up in Puppet 3.2.

#38 Updated by Anonymous about 3 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

summary: Merged into master as 4bfad67. This should be released in Puppet 3.2. Thanks again for the contribution!

@all watchers

Could you please grab a copy of the master branch and try out the new behavior? If it’s a PITA for you to run Puppet from source in this manner, I’d be happy to build an RPM for people to try out, but I’d prefer to do it only for EL 6 if possible.

Please comment here if you’re able to try out the pre-release version of this patch in order to help us verify we’ve fixed this issue for the most common cases.

Thanks, -Jeff

#39 Updated by Anonymous about 3 years ago

Preview RPMs

I’ve published Enterprise Linux 6 packages from our master branch at http://git.io/tWBvcA.

These packages may have dependencies from the Puppet Labs release repository, which can be configured using yum install http://yum.puppetlabs.com/el/6Server/products/i386/puppetlabs-release-6-6.noarch.rpm.

Please try these packages out if you have a chance and let us know if the change resolves your issue or not.

Thanks, -Jeff

#40 Updated by Anonymous about 3 years ago

A copy of the markdown for posterity.

Pre-release RPM’s

Please try these packages and let us know if they resolve Puppet Labs Ticket #15561

#41 Updated by Jason Hancock about 3 years ago

My use case was that when submitting a report with the http report processor to an ssl-enabled url, it would break despite using a valid purchased ssl certificate.

First, I made sure that it was still failing on 3.1.1:

$ rpm -qa | grep puppet-server
puppet-server-3.1.1-1.el6.noarch

And then from my log file:

2013-03-30T22:55:40.014912+00:00 puppet puppet-master[2974]: Compiled catalog for 85029c04-81f5-4ee5-ab6d-a9d82944f8fe.cs1null in environment production in 0.14 seconds
2013-03-30T22:55:45.694997+00:00 puppet puppet-master[2974]: Report processor failed: Certname "/c=us/st=ut/l=salt lake city/o=the usertrust network/ou=http://www.usertrust.comutn - datacorp sgc" must not contain unprintable or non-ASCII characters

Then I upgraded to the packages you posted, bounced the puppetmaster, and re-ran my test.

$ rpm -qa | grep puppet-server
puppet-server-3.1.1-20130329git7541bae.1.el6.noarch

A different error message showed up in my logs:

2013-03-30T22:59:25.547990+00:00 puppet puppet-master[3532]: Starting Puppet master version 3.1.1
2013-03-30T22:59:26.912290+00:00 puppet puppet-master[3588]: Report processor failed: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [unable to get local issuer certificate for /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC]

#42 Updated by Dustin Mitchell about 3 years ago

Jason, that’s a very different use-case. Did that work in 2.7.17? It looks like what’s happening is that the master is trying to verify the reports URL’s SSL certificate, and is not finding a root CA certificate that it knows about. I assume that the certificate named in the error message (CN=UTN – DATACorp SGC) is the root? Is that certificate configured into your master somehow? If not, I don’t think this will work (puppet doesn’t, and shouldn’t, ship with the list of trusted CAs that web browsers do). If so, how have you configured it?

#43 Updated by Jason Hancock about 3 years ago

It doesn’t work in 2.7.x because I believe submitting reports to an SSL enabled reporturl wasn’t supported until Puppet 3.0.

I haven’t done any special configuration for the certificate on the puppetmaster as the http report processor documentation (http://docs.puppetlabs.com/references/latest/report.html#http) didn’t specify that I had to do any sort of configuration on the master aside from setting the reporturl. I simply purchased the cert from Namecheap and configured apache on my webserver that is receiving the reports to use it.

#44 Updated by Dustin Mitchell about 3 years ago

OK, then I think that’s either a misconfiguration (not including the namecheap CA cert in the puppet configuration, although if that’s required it should be documented) or a different bug (puppet uses its internal list of CAs rather than the default from libcurl or something like that when submitting reports via HTTPS). It happened that your use-case showed the error message described in this ticket first, before it got to the “unable to get local issuer certificate” error, which is the real problem for you.

@Jeff, how do you think validation of such HTTPS servers should be handled?

#45 Updated by Anonymous about 3 years ago

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 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

#46 Updated by Dustin Mitchell about 3 years ago

OK, the docs should be updated to indicate that limitation, then (and it’s not so bad to work around with ssl_client_ca_auth). Jason, do you mind opening a new Redmine ticket for that documentation change? If you can also make a pull request to fix it, that would of course be awesome, but I can take care of it otherwise.

#47 Updated by Dustin Mitchell about 3 years ago

I tested again with my shell script (https://gist.github.com/djmitche/5233972) and it worked just fine, so +1 from me :)

#48 Updated by Dustin Mitchell about 3 years ago

For the record (and since Jeff McCune and I talked about this), I can also verify that Puppet minds the extendedKeyUsage fields of a certificate.

This means that certs for masters can be signed with extendedKeyUsage = serverAuth, and agents with clientAuth. Then agent certs aren’t usable to impersonate a puppet master.

#49 Updated by Anonymous about 3 years ago

Dustin Mitchell wrote:

I tested again with my shell script (https://gist.github.com/djmitche/5233972) and it worked just fine, so +1 from me :)

Excellent! I also took your shell script and made it into an automated acceptance test, so hopefully we don’t regress on this issue again.

The acceptance tests configures Puppet in the manner you specified when we worked together last week. There are email addresses in the subject of the CA certificate and in one test case for the client certificate.

The acceptance test is at https://github.com/puppetlabs/puppet/pull/1572

-Jeff

#50 Updated by Ben Jones about 3 years ago

The patched version works for our use case (inhouse chained CA).

#51 Updated by Anonymous about 3 years ago

Acceptance tests that cover Dustin’s use case with Apache + Passenger have been committed to master in 8762b7a.

Thanks for trying out the pre-release RPM’s. We’re hoping to get an RC of Puppet 3.2 released in the next few weeks.

-Jeff

#52 Updated by Matthaus Owens about 3 years ago

  • Status changed from Merged - Pending Release to Closed

Released in Puppet 3.2.0-rc1

#53 Updated by Matthaus Owens about 3 years ago

Released in Puppet 3.2.0-rc1

Also available in: Atom PDF