Puppet users - Jan 2010 - Comments on #3120 - chained CAs for issuing certs?

I think my bug writeup on #3120 is less than wonderful but I wanted to point it
up to the list here in hope of inspiring further comment.

The situation is that I followed first Ohad''s doc on PuppetScalability,
then Jeff McCune''s MultipleCertificateAuthorities writeup, to no avail.
I tried both following the directions and then tweaking things which seemed to
be wrong (of which #3120 is one offshoot) and got no love.  Puppet
doesn''t seem to want to verify a multi-level cert, even when all the CA
certificates are available to it concatenated together in $ssldir/certs/ca.crt. 
(''openssl verify -CAfile ca.crt'' returns OK)

Ultimately I gave up, like Paul L''s thread "SSL Makes My Brain
Bleed", my brain bled too and I ended up following his hard-fought wisdom
from

http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b

I.e. Setup one host to be the CA, set ca=false on the other puppetmasters, and
use puppetd --ca_server=puppetca on initial run to point the clients at it.  I
sort of feel like I should have done this last week and saved much
tooth-gnashing.

So my question to the larger audience is, has *anybody* really gotten this to
work? Both the wiki docs are kind of old and, at least in
MultipleCertificateAuthorities case, have some pretty serious caveats, like
"This isn''t working".  Even Ohad''s setup says
"Please note that webrick is at this time (0.24.4) unable to handle the
certs in a correct way to get this setup working."

Thanks
-=Eric

-- 
death needs time for what it kills to grow in

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Eric,

I''ve a working chained CA setup working for a few years now.

what exactly were your problems? did you remember to add the top level CA
pub key?

I''ll try to make some time for this issue next week, and to rebuild the
ca
setup in a lab.

on a side note, I''m not 100% sure if it make sense to go all of this
extra
work instead of using a centralized CA.

cheers,
Ohad

On Thu, Jan 28, 2010 at 9:03 AM, Eric Sorenson <ahpook@gmail.com> wrote:
> I think my bug writeup on #3120 is less than wonderful but I wanted to
> point it up to the list here in hope of inspiring further comment.
>
> The situation is that I followed first Ohad''s doc on
PuppetScalability,
> then Jeff McCune''s MultipleCertificateAuthorities writeup, to no
avail. I
> tried both following the directions and then tweaking things which seemed
to
> be wrong (of which #3120 is one offshoot) and got no love.  Puppet
doesn''t
> seem to want to verify a multi-level cert, even when all the CA
certificates
> are available to it concatenated together in $ssldir/certs/ca.crt.
>  (''openssl verify -CAfile ca.crt'' returns OK)
>
> Ultimately I gave up, like Paul L''s thread "SSL Makes My
Brain Bleed", my
> brain bled too and I ended up following his hard-fought wisdom from
>
> http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b
>
> I.e. Setup one host to be the CA, set ca=false on the other puppetmasters,
> and use puppetd --ca_server=puppetca on initial run to point the clients at
> it.  I sort of feel like I should have done this last week and saved much
> tooth-gnashing.
>
> So my question to the larger audience is, has *anybody* really gotten this
> to work? Both the wiki docs are kind of old and, at least in
> MultipleCertificateAuthorities case, have some pretty serious caveats, like
> "This isn''t working".  Even Ohad''s setup says
"Please note that webrick is
> at this time (0.24.4) unable to handle the certs in a correct way to get
> this setup working."
>
> Thanks
> -=Eric
>
> --
> death needs time for what it kills to grow in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 1/27/10 5:03 PM, Eric Sorenson wrote:
> Ultimately I gave up, like Paul L''s thread "SSL Makes My
Brain Bleed", my brain bled too and I
> ended up following his hard-fought wisdom from
>
> http://groups.google.com/group/puppet-users/msg/89b75ebe91c5985b
>
> I.e. Setup one host to be the CA, set ca=false on the other puppetmasters,
and use puppetd
> --ca_server=puppetca on initial run to point the clients at it.  I sort of
feel like I should
> have done this last week and saved much tooth-gnashing.
>
This is what I did and it Just Works(tm). I set ca_server in puppet.conf on
clients, though.

The only annoying part is that if I ever revoke something, I have to distribute
the CRL to my
puppetmasters. Oh well.

-scott

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, 27 Jan 2010, Scott Smith wrote:
> The only annoying part is that if I ever revoke something, I have to 
> distribute the CRL to my puppetmasters. Oh well.
openssl discusses this in the ''verify'' man page

Nothing says a certificate has to be of any particular 
duration.  A certificate outside of its validity date whould 
not be trusted anyway [dunno that the code checks this, but 
...]

Why not issue them out just a month, and then let them expire?

If needed again, push a new one with a new expiration date 
out.  Let the passage of time and a system design handle the 
implicit ''no longer trusted'' decision, to avoid needing to 
maintain a CRL list of more than a couple of entries tops

-- Russ herrold

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.