Possible to disable puppets internal CA, and use wildcard certs from DigiCert CA?
Jed
i'm new to puppet, sorry if the question comes off a little green-
thumb
I have a puppet server and a puppet client (both running latest
versions)
we have wildcard certs for all our internal domains, we use these
certs for SSL ldap posix auth, apache, jetty..etc.etc.
ie.
*.priv.tech.com
instead of puppet generating the certs and doing the signing of the
client request, would it be possible to have puppet use these wildcard
ssl certs instead?
So when i stand up an instance (centos on vmware) , it will
automatically have the certs built into the template and that instance
can talk to the puppet master without having to manually sign every
puppet client. I've read that i can turn auto-sign=on , but that is a
gapping security hole.
I basically want to remove the signing step and have all instances
automatically talk/trust the puppet master using our wildcard ssl
certs.
is this possible?
Daniel Pittman
> i'm new to puppet, sorry if the question comes off a little green-
> thumb
We all start off that way. :)
> I have a puppet server and a puppet client (both running latest
> versions)
>
> we have wildcard certs for all our internal domains, we use these
> certs for SSL ldap posix auth, apache, jetty..etc.etc.
>
> ie.
> *.priv.tech.com
>
> instead of puppet generating the certs and doing the signing of the
> client request, would it be possible to have puppet use these wildcard
> ssl certs instead?
Yes. On the other hand, you will very quickly run into a problem:
The puppet master uses the name in the SSL certificate that the client
supplies as the "node" identifier. So, if you use that wildcard for
your nodes you will not be able to uniquely identify them. You would
have to have the same manifest on all of them, or reinvent all the
distinctions that puppet already makes.
> So when i stand up an instance (centos on vmware) , it will
> automatically have the certs built into the template and that instance
> can talk to the puppet master without having to manually sign every
> puppet client. I've read that i can turn auto-sign=on , but that is a
> gapping security hole.
Well, it allows anyone to become a "known" node is your
infrastructure. They can then get whatever configuration a default
node gets; historically, this has been a fatal error that the node is
unknown in my configurations:
node default {
fail("node ${fqdn} is not a known host!")
}
The degree of security hole is pretty strictly limited, because
holding an SSL certificate gives you a token that lets you identify
yourself to the puppet master, not a token that allows you to do
anything more exciting.
> I basically want to remove the signing step and have all instances
> automatically talk/trust the puppet master using our wildcard ssl
> certs.
>
> is this possible?
Probably not usefully to you, no. You might better aim to integrate a
stage into your host build process that will generate the certificate
on the server and allow it to download.
Regards,
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
KC Braunschweig
Just to clarify as I've been having this discussion recently, the
problem is the wildcard certs. If you wanted to generate individual
certs for each client system during your provisioning process and drop
it in for puppet to use rather than using puppet as a CA, that should
work, right?
Also, while it doesn't address the wildcard issue, you might be
interested in the link below. It is designed to explain a strategy for
using multiple CAs but seems like you could also use this approach to
integrate with an existing PKI.
http://projects.puppetlabs.com/projects/puppet/wiki/Multiple_Certificate_Authorities
KC
Nigel Kersten
On Fri, Jan 28, 2011 at 11:02 AM, Daniel Pittman <dan...@puppetlabs.com> wrote:
> On Fri, Jan 28, 2011 at 06:47, Jed <jedb...@gmail.com> wrote:
>> is this possible?Just to clarify as I've been having this discussion recently, the
>
> Probably not usefully to you, no. You might better aim to integrate a
> stage into your host build process that will generate the certificate
> on the server and allow it to download.
problem is the wildcard certs. If you wanted to generate individual
certs for each client system during your provisioning process and drop
it in for puppet to use rather than using puppet as a CA, that should
work, right?
Also, while it doesn't address the wildcard issue, you might be
interested in the link below. It is designed to explain a strategy for
using multiple CAs but seems like you could also use this approach to
integrate with an existing PKI.
http://projects.puppetlabs.com/projects/puppet/wiki/Multiple_Certificate_Authorities
KC
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Derek J. Balling
On Jan 28, 2011, at 2:02 PM, Daniel Pittman wrote:
> Yes. On the other hand, you will very quickly run into a problem:
>
> The puppet master uses the name in the SSL certificate that the client
> supplies as the "node" identifier. So, if you use that wildcard for
> your nodes you will not be able to uniquely identify them. You would
> have to have the same manifest on all of them, or reinvent all the
> distinctions that puppet already makes.
I thought someone pointed out (when I went on one of my rants about the SSL/CA stuff in puppet) that there's a configuration-option to tell the puppetmaster to use the $fqdn fact as the nodename instead?
So it shouldn't be THAT hard, if it's just a config-option.
D