Puppet

I will throw in my two cents, since I am up against the exact same problem. I am using a Cert chain that is part of an existing PKI solution.

The issue as I have diagnosed it is related to CRL being found

I have filed two bugs related to this:

1. All puppetmasterd will run in CA mode http://projects.reductivelabs.com/issues/3141 As such, the server will respond to REST requests for a CRL, creating one if necessary.

2. I cannot seem to find a way to tell the Client (Configurer/Agent) to stop looking for and using the CRL returned by its puppetmaster. http://projects.reductivelabs.com/issues/3168

Detail At some point, the Puppet::SSL::Host.ssl_store will initialize a OpenSSL::X509::Store with the certificate from Puppet[:localcert]

Optionally it will look for a CRL which is either cached locally or pulled from REST. If a CRL is found, it then enables “CRL checking” by flag in the SSL store (for use during SSL verification process). And given the above bugs, some a CRL can almost always be found.

if crl = Puppet::SSL::CertificateRevocationList.find("ca")
    Puppet.info "USING CRL: #{crl.content.issuer} Revoked: #{crl.content.revoked}"
    @ssl_store.flags = OpenSSL::X509::V_FLAG_CRL_CHECK_ALL|OpenSSL::X509::V_FLAG_CRL_CHECK
    @ssl_store.add_crl(crl.content)
end

I think (though I don’t know openssl that well), that for each cert in the verification chain, there must exist a CRL (named by ‘issuer’) signed by that cert. And with only 1 CRL and 3 certs in the CA chain, all verification will fail. For me, the failure happens when the current cert is Cert 2, (where 0 is the identity cert to verify, 1 signed 0, 2 signed 1, etc…) and the error returned during verify is (3): unable to get certificate CRL

Summary In the standard “Puppet is the CA” use case, the Cert chain is only one deep, so only one CRL (from the CA) is needed. If the cert chain is deeper, the CRL solution, as implemented breaks down, and Cert verification will always fail.

Sidenote FWIW I also filed this request: http://projects.reductivelabs.com/issues/3169

The code I added showed much more clearly what is happening in the X509 verification process which happens as part of SSL negotiation. ruby/OpenSSL does not seem to be very informative at this level. It may not be worth actually putting in the released code, but it may help you determine what is really going wrong.

After investigating this the R&D team have concluded that we don’t have the ability to reduce this to a small, safe fix that would match the 2.6 branch guidelines, so our strong recommendations are:

1. We should make this a statler feature, rather than a 2.6 feature.
2. We need some sort of radical improvement; half our pain comes from the Ruby libraries for managing SSL, and their special behaviour in terms of mutating what we say into what they think we intended to say internally.

Perfect. Thank you for the research time.