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

Puppet client does not update and does consult the crl during authentication

Added by Alexander Piavlo over 4 years ago. Updated about 2 years ago.

Status:AcceptedStart date:08/18/2011
Priority:HighDue date:
Assignee:-% Done:

0%

Category:security
Target version:-
Affected Puppet version:development Branch:
Keywords:CRL

We've Moved!

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

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-2310


Description

I my tests puppet client never updates it’s /var/lib/puppet/ssl/ca/ca_crl.pem from the master even if I delete it – it is not fetched from master then client runs.

Another issue is that puppet client does not consult the crl – after revoking cert of node dev2.internal on master – and manually copying /var/lib/puppet/ssl/ca/{ca_crl.pem,inventory.txt} to client mon1a.internal and restarting the client to make sure it can pickup the crl changes – I was still able to trigger client puppet run on mon1a.internal from dev2.internal.

It looks like puppet – client does not take the crl into consideration then authenticating.

The relevant config on mon1a.internal is

 # allow all authenticated nodes to trigger puppet run
path /run
method save
auth yes
allow *

this ACL comes first in the auth.conf file

And this is the command I used to triger puppet run from dev2.internal

 curl --cert /var/lib/puppet/ssl/certs/dev2.internal.pem --key  /var/lib/puppet/ssl/private_keys/dev2.internal.pem --cacert /var/lib/puppet/ssl/certH "Content-Type: text/pson" -d "{}" https://mon1a.internal:8139/production/run/dev2.internal

Could these problems be taken care of?

Thanks Alex

Ed- description from #9205 which is closely related included

We came across this in a weird way. Last night we reissued the CA certificate, which had expired. We then reissued the puppetmaster and puppetca certificate (which we had to do for RHEL4 and RHEL5 but all other systems were happy without this step). We then noticed on RHEL4 and RHEL5 that they were still complaining about cert validation, but ONLY for getting plugins and sending the report (it got a catalog and was able to get files for modules, etc, just fine). We did an strace and found this was the only times it was trying to get a CRL (and was failing). Why is this the only time the CRL was in play?


Related issues

Related to Puppet - Feature #3143: Fully support multiple CAs and CA trust chains in Puppet Closed 02/03/2010
Duplicated by Puppet - Bug #9205: CRL only consulted for plugins and reports? Duplicate 08/25/2011
Duplicated by Puppet - Feature #16842: CRLs on nodes other than the CA should occasionally update Duplicate 10/07/2012

History

#1 Updated by James Turnbull over 4 years ago

  • Category set to SSL
  • Status changed from Unreviewed to Needs More Information
  • Assignee set to Alexander Piavlo

What version and platform please?

#2 Updated by Alexander Piavlo over 4 years ago

Puppet 2.7.3 CentOS 5.6

#3 Updated by James Turnbull over 4 years ago

  • Status changed from Needs More Information to Needs Decision
  • Assignee changed from Alexander Piavlo to Nigel Kersten
  • Affected Puppet version set to 2.7.3
  • Keywords set to CRL

Nigel – I think there are a series of bugs related to SSL/CRL including #9205 and a series of others. That’s not counting the broken chained CA CRL issues.

#4 Updated by Nigel Kersten over 4 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Target version set to 2.7.x

#5 Updated by Nigel Kersten over 4 years ago

  • Priority changed from Normal to Urgent

#6 Updated by Nigel Kersten over 4 years ago

  • Description updated (diff)

#7 Updated by Nigel Kersten over 4 years ago

  • Description updated (diff)

#8 Updated by eric sorenson almost 4 years ago

  • Priority changed from Urgent to Normal

#9 Updated by Anonymous over 3 years ago

  • Target version deleted (2.7.x)

#10 Updated by Daniele Sluijters over 2 years ago

  • Category changed from SSL to security
  • Affected Puppet version changed from 2.7.3 to development

This bug still occurs with 3.3.1. Though the CRL is initially downloaded from a CA and ‘cached’ that cache is never cleared causing multi-master setups to run with an increasingly outdated CRL.

For reference: https://ask.puppetlabs.com/question/3843/multiple-puppet-masters-with-single-ca-server/

I think this bug is dangerous especially because the separate CA thing is new and people don’t realise, nor is it documented, that this is the current behaviour.

#11 Updated by Daniele Sluijters over 2 years ago

  • Priority changed from Normal to High

#12 Updated by Adrien Thebo about 2 years ago

Redmine Issue #9118 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-2310

Also available in: Atom PDF