The Puppet Labs Issue Tracker has Moved:

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 See the following page for information on filing tickets with JIRA:

Feature #16842

CRLs on nodes other than the CA should occasionally update

Added by Shane Madden over 3 years ago. Updated over 3 years ago.

Status:DuplicateStart date:10/07/2012
Priority:NormalDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:3.0.0 Branch:

We've Moved!

Ticket tracking is now hosted in JIRA:


Currently, agents cache the CRL file at $ssldir/crl.pem from the CA a single time, and use the cached copy for certificate validation.

This is less than ideal, because clients seem to never update their cached revocation list unless it’s deleted or something else outside of normal operation occurs (correct me if I’m wrong on this?). Probably not too big of a deal for client agents' validation of the master that they’re connecting to – if you revoke a master’s cert, then you probably took the server down and don’t need to worry about the revoked cert being incorrectly treated as valid.

However, this is a potential problem for masters that aren’t the CA; they never get a new CRL even after it’s updated from a revoke, and they’ll happily authenticate client agents (or non-agents that have a cert for API use) whose certs have been long since revoked by the CA master.

Is there a good way to have agents attempt to pull a new CRL every so often (once a day or once a week?), while still being ok with their cached version if they’re unable to complete a re-fetch of a new copy of the CRL? It’s pretty easy to implement a module to update the CRL file occasionally, but this seems like it belongs in the agent code itself.

I also think it’d be nice to have the ability to set a shorter-than-five-year lifetime on the CRL to force CRL updates, but that’s likely a far more complicated and involved change (might as well just do the OCSP implementation in #10111 at that point, I’m guessing?).

By the way – the default auth.conf could probably stand to be updated to allow non-authenticated requests to /certificate_revocation_list, as the current defaults block clients from getting the CRL when proxying /certificate.* traffic from non-CA masters to the CA master.

Related issues

Related to Puppet - Feature #3143: Fully support multiple CAs and CA trust chains in Puppet Closed 02/03/2010
Duplicates Puppet - Bug #9118: Puppet client does not update and does consult the crl du... Accepted 08/18/2011


#1 Updated by eric sorenson over 3 years ago

  • Status changed from Unreviewed to Duplicate

Believe this is a dup of #9118.

Also available in: Atom PDF