I am using puppet agent 3.4.3 and still see this as an issue.  I found
these tickets in the old tracking system related to my intended objectives:
* https://projects.puppetlabs.com/issues/3143
  https://projects.puppetlabs.com/issues/3770
  https://projects.puppetlabs.com/issues/14550
  https://projects.puppetlabs.com/issues/15404

I have not found any similar tickets in JIRA and would like to know if
interest was lost in this capability or if it was addressed and I am
missing something with my configuration.  I opted to configure "Option 3:
Two Intermediate CAs Issued by One Root CA" as outlined at
http://docs.puppetlabs.com/puppet/latest/reference/config_ssl_external_ca.html#option-3-two-intermediate-cas-issued-by-one-root-ca
.

I can get everything working properly by setting the following in
puppet.conf on each agent:
  certificate_revocation = false

I would rather leave that at the default, true, but it appears this is not
possible at this time.

According to
http://docs.puppetlabs.com/references/latest/configuration.html#certificaterevocation,
this appears to be a known limitation.
  certificate_revocation
  Whether certificate revocation should be supported by downloading a
Certificate Revocation List (CRL) to all clients. If enabled, CA chaining
will almost definitely not work.
  Default: true

The documentation on using an external CA makes no reference to this
limitation and even claims that CRL's are supported with all 3 external CA
configurations.  See
http://docs.puppetlabs.com/puppet/latest/reference/config_ssl_external_ca.html#revocation
  "Certificate revocation list (CRL) checking works in all three supported
configurations, so long as the CRL file is distributed to the agents and
masters using an “out of band” process. Puppet won’t automatically update
the CRL on any of the components in the system."

This statement is false with option 3.  The nice thing about option 3 is
that is prevents agent certificates from being used to act as a master.
 With some name resolution trickery someone could cause havoc if they have
certificates that allow an arbitrary machine to act as a puppet master.

There have been multiple approaches proposed to work around this limitation
in the product:
  - OCSP support, negating the need to support CRLs, though this would only
solve the problem for CA's that support OCSP
  - CRL directory (versus file) support, comparable to
Apache's SSLCARevocationPath

Curious where this stands.

Thanks,
Axton Grams

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJeeBBwWjxgfvAGBq1Wa7rxLSntzwWVNh_wmhWD67WVFLUGGew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to