On Mon, Jul 12, 2010 at 11:21 AM, Bryan Kearney <[email protected]> wrote: > On 07/12/2010 01:31 PM, Al Tobey wrote: >> On Mon, Jul 12, 2010 at 5:41 AM, Bryan Kearney<[email protected]> >>> On 07/09/2010 07:16 PM, Al Tobey wrote: >>>> I've been working on setting up a puppet deployment using an external CA >>>> that signs certs for my puppet masters rather than using the internal >>>> self-signed certs. Along the way, I wanted to try having the >>>> certificate chain available on the agents so I added the >>>> "localcacertdir" option to puppet. localcacertdir points at a >>>> directory with all the required certs in it with the hash symlinks set >>>> up as openssl likes them (see openssl x509 -hash). I later found that >>>> this option is not necessary for normal operation once the CRL checks >>>> are relaxed a bit with the next patch, and am sending it here in case >>>> somebody else will find use for it. >>> >>> What would this directory look like? I have a similar goal (external >>> Certificate management) and I have not run across a standard layout. I am by >>> no means an openssl expert though :) >> >> It's just a plain flat directory with all of the certificates in their >> own files (or bundles). After adding any certs you just need to run >> cacertdir_rehash (that's what it's called on RHEL - other distros name >> it differently). It's just a shellscript that does: >> >> cd $DIR >> for $cert in * >> do >> hash=`openssl x509 -hash -noout -in $cert`&& ln -sf $cert $hash.0 >> done >> > > The issue I found with integrating with an external cert system was that > puppet assumed that the files were all named hostname.pem with the location > of the file being different.
Since I'm actually letting Puppet play CA for its agents, but with a subordinate CA certificate, this hasn't been a problem for me. > It looks like this patch would only support an > external source if the private, pub, and cert were all one file. As I said, this option may not be useful to most people. If you have a particularly long certificate chain or many CA's in play, it is necessary. The easiest contrived scenario is replacing your CA certs with overlap. In the end the option is exactly equivalent to Apache's SSLCACertificatePath. http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcacertificatepath >>>> The second patch relaxes the CRL checking flags sent to openssl so that >>>> verification can succeed even if all of the CRL's in the certificate >>>> chain are not available. With this option enabled (default is disabled >>>> to match current behavior), only the first certificate in the chain's >>>> CRL (the puppet master's CA cert) is verified. This makes my setup >>>> work well enough for me to move forward, although the correct solution >>>> is to distribute the entire CRL chain and have puppet use it. I'm >>>> still learning the internals of puppet and ruby at the same time so that >>>> will have to wait for another day. >>> >>> What is the value of distributing the CRLs as opposed to the server doing >>> it? Is this a performance thing? >> >> This patch requires the server to distribute the CRL's. The change >> it makes is to relax the CRL checking so it only checks the first >> cert. So when I said "distribute the whole CRL chain," what I meant >> was that it'd be nice if Puppet could push CRL's for multiple >> certificates rather than just the current master's certificate. OCSP >> might be the only sane thing to do in these cases. > > What I am not clear on is why should the server distribute it? Is it a > performance issue? No, not performance related at all. It's just one-stop shopping at this point. If I was running an entirely separate PKI system, I'd be implementing OCSP and/or PRQP (http://openca.org/projects/prqpd/) support. I want to retain most of Puppet's turn-key PKI features but keep control of certificate trust elsewhere. -Al -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
