On 07/12/2010 01:31 PM, Al Tobey wrote:
On Mon, Jul 12, 2010 at 5:41 AM, Bryan Kearney<[email protected]> wrote:
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. It looks like this patch would
only support an external source if the private, pub, and cert were all
one file.
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?
-- bk
--
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.
