just my 2 cents on the matter, afaik I'm the only one running puppet with a working chained ca setup.
the rewrite of the ssl methods in 0.25.x branch, broke the chained ca setup mostly because it added CRL checking, this was partly fixed in 0.25.5 with the ability to disable the CRL (#3640), but does not really address the root cause(just disables the checks). The CRL distribution is broken complelty, as the CRL will be distributed only if none exists on the client, and will not be distributed any more (e.g. even if the CRL has been changed, the client will not know about it). another major issue is #3770, which at the moment, puppet will rewrite the certs/ca file if it detects an additional (or non matching) certificate (e.g. top level ca). the way I've been handing it so far is: use only 0.24.x (which becomes a real problem now). add the top level ca in the host post install after puppet has gotten the certificate from the mid level ca. I am happy that you guys invest some time into it, as I am really short of resources lately to attack it.. Ohad On Tue, Jul 13, 2010 at 2:38 AM, Al Tobey <[email protected]> wrote: > 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]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- 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.
