Axton
2014-Mar-24 00:08 UTC
[Puppet Users] External CA - Proper Support for Certificate Chaining
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 puppet-users+unsubscribe@googlegroups.com. 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.