Issue #3168 has been updated by Nicholas Veeser.
Adding to the end of this. The work around is not really a work-around. Lots of "Actions" in the configurer will initialize the Puppet::SSL::Host.ssl_store. When you initialize the ssl_store, it tries to retrieve a CRL from the CA. With my workaround this will fail. This will cause the "Action" to fail. The PluginSync Action seems to be non-fatal, but leaves the ssl_store in a working and configured state. (Um...that's a weird design artifact) Any other action which initializes the ssl_store will fail (ie a Catalog retrieval) which will cause the "puppet client run" to fail. creating a patch for myself. I will upload it here. ---------------------------------------- Bug #3168: Cannot disable use of CRL in puppetd http://projects.reductivelabs.com/issues/3168 Author: Nicholas Veeser Status: Unreviewed Priority: Normal Assigned to: Category: SSL Target version: Affected version: 0.25.3 Keywords: Branch: Upgrading from 0.24.8 -> 0.25.3 I am using puppet as a CA, but only manually, using puppetca client. There is no puppetmasterd process currently acting as the CA. (though I cannot seem to turn it off. see: http://projects.reductivelabs.com/issues/3141) Here is the behavior as I understand it. Puppet::SSL::Host.ssl_store sets up the SSL context for the host and has this: def ssl_store... ... # If there's a CRL, add it to our store. if crl = Puppet::SSL::CertificateRevocationList.find("ca") Puppet.debug "found crl" @ssl_store.flags = OpenSSL::X509::V_FLAG_CRL_CHECK_ALL|OpenSSL::X509::V_FLAG_CRL_CHECK @ssl_store.add_crl(crl.content) end .... Puppetd runs with Puppet::SSL::Host.ca_location = :remote. This sets 'CertificateRevocationList' to have a cache set to a :file terminus and main terminus set to :rest So when looking for a CRL, it will - first look for a file (which is the "cache") - then look in REST. - If found via REST, cache in file This will look at the :ca_server (or :server) for the CRL. Due to http://projects.reductivelabs.com/issues/3141, my 0.25.3 puppetmasterd will run as a CA no matter what. So each puppetmaster will create an empty CRL (issued by itself), and return it. The client will cache the CRL, and try to use that. Since it is not issued by the same CA Cert as the host identity Certs, then all cert verification will fail. Even if I get a ca_crl from the Puppet CA, which has the correct issuer line for the Signing cert, I cannot seem to get any CRL to work. If it finds a CRL, and passes it to OpenSSL, the verify fails. (the current error, after much wrangling, is (3) X509_V_ERR_UNABLE_TO_GET_CRL: unable to get certificate CRL) This maybe because my cert chain is longer that 1 (0,1), but is actually 4 certs (0,1,2,3). I assume that OpenSSL is failing at trying to find a CRL for every signing cert in the chain. *Workaround* Set ca_server to some host that is not running as a puppetmaster. Results in: err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': Connection refused - connect(2) But at least the CRL is empty. *Summary* There seems to be no way for the puppetd client (Configurer?) to distinguish between: - The CRL is unavailable due to error, Certificates cannot be verified. - The CRL does not exist, don't try to use one. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
