External CA - Proper Support for Certificate Chaining

[Axton]

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