Ohad Levy
2008-May-02 02:10 UTC
[Puppet Users] Certificate hierarchy - multiple puppet masters setup
Hi,
As some people in the list has requested, I''ll try to describe the
setup we
currently use with multiple puppet masters and "HA/failover".
I tried uploading it to the wiki, but it seems to be down at the time of
writing this page...
As we are deploying puppet infrastructure in multiple sites it was important
for us to have a centralized management for puppet, but a non centralized
"service", we wanted to have the option to switch between puppet
masters,
and did not like the idea of a single CA for all of our infrastructure.
the main reason against a common ca was, as we are really spread over the
world and its common to install 50+ servers in a time frame of a few hours,
we didn''t want to introduce any type of dependencies.
additionally, revoking works better this way, and well... we just wanted to
make it work ;)
Using our solution, you could also use real root CA, your company root or
self sign certificate, in some cases it could make sense not to use a self
sign if you want to reuse the certificates for Apache, ldap etc.
Since all of our puppet masters are managed as well, we have one root puppet
master (i.e. puppet master of the puppet masters), we called it the
puppeteer.
the puppeteer installation is like a regular puppet master installation.
We are using Apache + Mongrel: on all puppet masters you should have
something like that in your Apache configuration (that''s just the ssl
part):
<VirtualHost *:8140>
SSLEngine on
SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
SSLCertificateFile /var/lib/puppet/ssl/certs/your.fqdn.com.pem
SSLCertificateKeyFile
/var/lib/puppet/ssl/private_keys/your.fqdn.com.pem
SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 3
SSLOptions +StdEnvVars
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
<Location />
than, let your second puppet master (the second level of the certificate
chain) request a certificate from the puppeteer.
setup an openssl.cnf file (just store it somewhere) with the following
content (adjust for your needs):
HOME = .
RANDFILE = $ENV::HOME/.rnd
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /var/lib/puppet/ssl
new_certs_dir = $dir/ca/signed
crl_dir = $dir/ca
database = $dir/index
certificate = $dir/ca/ca_crt.pem
serial = $dir/ca/serial
crl = $dir/ca/ca_crl.pem
private_key = $dir/ca/ca_key.pem
RANDFILE = $dir/private/.rand
x509_extensions = usr_cert
unique_subject = no
name_opt = ca_default
cert_opt = ca_default
default_crl_days= 30
default_days = 3650
default_md = sha1
preserve = no
policy = policy_anything
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048
default_keyfile = ./ca/ca_key.pem
default_md = sha1
prompt = no
distinguished_name = root_ca_distinguished_name
x509_extensions = v3_ca
string_mask = nombstr
[ root_ca_distinguished_name ]
commonName = XXXXXXXX
[ usr_cert ]
basicConstraints=CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
nsCaRevocationUrl https://puppeteer.your.domain.com/ca_crl.pem
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
basicConstraints = critical,CA:true
keyUsage = keyCertSign, cRLSign
[ crl_ext ]
authorityKeyIdentifier=keyid:always,issuer:always
on the puppetmaster:
than copy this file to your new puppet master (e.g. /tmp)
puppetmaster=fqdn
/usr/bin/perl -p -i -e "s/XXXXXXXX/$puppetmaster/" /tmp/openssl.cnf
/usr/bin/openssl req -new -nodes -key /var/lib/puppet/ssl/ca/ca_key.pem
-config /tmp/openssl.cnf -out /tmp/${puppetmaster}.csr -passin
file:/var/lib/puppet/ssl/ca/private/ca.pass
copy the ${puppetmaster}:/tmp/${puppetmaster}.csr back to the puppeteer
on the puppeteer
touch /var/lib/puppet/ssl/index
# Sign this request with the puppeteer''s CA keys
/usr/bin/openssl ca -config openssl.cnf -extfile openssl.cnf -extensions
v3_ca -in ${puppetmaster}.csr -out ${puppetmaster}.pem
-passin file:/var/lib/puppet/ssl/ca/private/ca.pass -batch
# Push the new certificate into place on the puppetmaster
scp ${puppetmaster}.pem ${puppetmaster}:/var/lib/puppet/ssl/ca/ca_crt.pem
in your installation process append the content of puppeteer
~puppet/ssl/ca/ca_crt.pem to /var/lib/puppet/ssl/certs/ca.pem on the client
now you should be able to use any puppet master that was signed this way.
Hopefully this helps someone,
Ohad
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Jeremy Pruitt
2008-May-03 06:28 UTC
[Puppet Users] Re: Certificate hierarchy - multiple puppet masters setup
Thank you so much. This worked and is exactly what I''ve been looking for. Are you doing this for failover should something happen to one of your puppetmasters? If so, how do the client''s know to go to the other puppetmaster server? Does the "server" configuration directive have a way a accepting multiple puppetmasters, or would you just change the hostname of the remaining functional server to that of the missing one? - Thanks again!!! :) On May 1, 7:10 pm, "Ohad Levy" <ohadl...@gmail.com> wrote:> Hi, > > As some people in the list has requested, I''ll try to describe the setup we > currently use with multiple puppet masters and "HA/failover". > > I tried uploading it to the wiki, but it seems to be down at the time of > writing this page... > > As we are deploying puppet infrastructure in multiple sites it was important > for us to have a centralized management for puppet, but a non centralized > "service", we wanted to have the option to switch between puppet masters, > and did not like the idea of a single CA for all of our infrastructure. > the main reason against a common ca was, as we are really spread over the > world and its common to install 50+ servers in a time frame of a few hours, > we didn''t want to introduce any type of dependencies. > additionally, revoking works better this way, and well... we just wanted to > make it work ;) > > Using our solution, you could also use real root CA, your company root or > self sign certificate, in some cases it could make sense not to use a self > sign if you want to reuse the certificates for Apache, ldap etc. > > Since all of our puppet masters are managed as well, we have one root puppet > master (i.e. puppet master of the puppet masters), we called it the > puppeteer. > the puppeteer installation is like a regular puppet master installation. > > We are using Apache + Mongrel: on all puppet masters you should have > something like that in your Apache configuration (that''s just the ssl part): > <VirtualHost *:8140> > SSLEngine on > SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA > SSLCertificateFile /var/lib/puppet/ssl/certs/your.fqdn.com.pem > SSLCertificateKeyFile > /var/lib/puppet/ssl/private_keys/your.fqdn.com.pem > SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem > SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem > SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem > SSLVerifyClient optional > SSLVerifyDepth 3 > SSLOptions +StdEnvVars > > RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e > RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e > RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e > > <Location /> > > than, let your second puppet master (the second level of the certificate > chain) request a certificate from the puppeteer. > > setup an openssl.cnf file (just store it somewhere) with the following > content (adjust for your needs): > HOME = . > RANDFILE = $ENV::HOME/.rnd > [ ca ] > default_ca = CA_default > [ CA_default ] > dir = /var/lib/puppet/ssl > new_certs_dir = $dir/ca/signed > crl_dir = $dir/ca > database = $dir/index > certificate = $dir/ca/ca_crt.pem > serial = $dir/ca/serial > crl = $dir/ca/ca_crl.pem > private_key = $dir/ca/ca_key.pem > RANDFILE = $dir/private/.rand > x509_extensions = usr_cert > unique_subject = no > name_opt = ca_default > cert_opt = ca_default > default_crl_days= 30 > default_days = 3650 > default_md = sha1 > preserve = no > policy = policy_anything > [ policy_match ] > countryName = match > stateOrProvinceName = match > organizationName = match > organizationalUnitName = optional > commonName = supplied > emailAddress = optional > [ policy_anything ] > countryName = optional > stateOrProvinceName = optional > localityName = optional > organizationName = optional > organizationalUnitName = optional > commonName = supplied > emailAddress = optional > [ req ] > default_bits = 2048 > default_keyfile = ./ca/ca_key.pem > default_md = sha1 > prompt = no > distinguished_name = root_ca_distinguished_name > x509_extensions = v3_ca > string_mask = nombstr > [ root_ca_distinguished_name ] > commonName = XXXXXXXX > [ usr_cert ] > basicConstraints=CA:FALSE > subjectKeyIdentifier=hash > authorityKeyIdentifier=keyid,issuer:always > nsCaRevocationUrl =https://puppeteer.your.domain.com/ca_crl.pem > [ v3_req ] > basicConstraints = CA:FALSE > keyUsage = nonRepudiation, digitalSignature, keyEncipherment > [ v3_ca ] > subjectKeyIdentifier=hash > authorityKeyIdentifier=keyid,issuer:always > basicConstraints = critical,CA:true > keyUsage = keyCertSign, cRLSign > [ crl_ext ] > authorityKeyIdentifier=keyid:always,issuer:always > > on the puppetmaster: > than copy this file to your new puppet master (e.g. /tmp) > puppetmaster=fqdn > /usr/bin/perl -p -i -e "s/XXXXXXXX/$puppetmaster/" /tmp/openssl.cnf > /usr/bin/openssl req -new -nodes -key /var/lib/puppet/ssl/ca/ca_key.pem > -config /tmp/openssl.cnf -out /tmp/${puppetmaster}.csr -passin > file:/var/lib/puppet/ssl/ca/private/ca.pass > copy the ${puppetmaster}:/tmp/${puppetmaster}.csr back to the puppeteer > > on the puppeteer > touch /var/lib/puppet/ssl/index > # Sign this request with the puppeteer''s CA keys > /usr/bin/openssl ca -config openssl.cnf -extfile openssl.cnf -extensions > v3_ca -in ${puppetmaster}.csr -out ${puppetmaster}.pem > -passin file:/var/lib/puppet/ssl/ca/private/ca.pass -batch > > # Push the new certificate into place on the puppetmaster > scp ${puppetmaster}.pem ${puppetmaster}:/var/lib/puppet/ssl/ca/ca_crt.pem > > in your installation process append the content of puppeteer > ~puppet/ssl/ca/ca_crt.pem to /var/lib/puppet/ssl/certs/ca.pem on the client > > now you should be able to use any puppet master that was signed this way. > > Hopefully this helps someone, > Ohad--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
James Turnbull
2008-May-03 08:48 UTC
[Puppet Users] Re: Certificate hierarchy - multiple puppet masters setup
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ohad Levy wrote:> Hi, > > As some people in the list has requested, I''ll try to describe the setup > we currently use with multiple puppet masters and "HA/failover". > > I tried uploading it to the wiki, but it seems to be down at the time of > writing this page... >Ohad The wiki is up - perhaps merge this into the http://reductivelabs.com/trac/puppet/wiki/PuppetScalability page? Regards James Turnbull - -- James Turnbull (james@lovedthanlost.net) Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIHCbh9hTGvAxC30ARAsALAJ4ks1Zq1tyFLy5xy/4MQaN0axkHXgCfca7+ fqbg98hnwgJ/3a3SezknKcQ=s2em -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ohad Levy
2008-May-03 10:17 UTC
[Puppet Users] Re: Certificate hierarchy - multiple puppet masters setup
Hi, you are welcome. at this point in time, we have only one server per site, with apache as a load balancer, so far, we didn''t need to expand to more than one server per site. therefor, in the case of a failure, we just play around with the dns alias of puppet. you cannot change the hostname, as the certificate verification would fail, currently each site certificate would be verified, if its not fqdn,puppet or puppet.domain it would fail. maybe this could be done differently, I would be really happy if pupept would support DNS SRV records lookup, if that would be the case, it would be possible to do the balancing in the client rather on the server side. Ohad On Sat, May 3, 2008 at 2:28 PM, Jeremy Pruitt <jeremypruitt@gmail.com> wrote:> > Thank you so much. This worked and is exactly what I''ve been looking > for. > > Are you doing this for failover should something happen to one of your > puppetmasters? If so, how do the client''s know to go to the other > puppetmaster server? > > Does the "server" configuration directive have a way a accepting > multiple puppetmasters, or would you just change the hostname of the > remaining functional server to that of the missing one? > > - Thanks again!!! :) > > On May 1, 7:10 pm, "Ohad Levy" <ohadl...@gmail.com> wrote: > > Hi, > > > > As some people in the list has requested, I''ll try to describe the setup > we > > currently use with multiple puppet masters and "HA/failover". > > > > I tried uploading it to the wiki, but it seems to be down at the time of > > writing this page... > > > > As we are deploying puppet infrastructure in multiple sites it was > important > > for us to have a centralized management for puppet, but a non > centralized > > "service", we wanted to have the option to switch between puppet > masters, > > and did not like the idea of a single CA for all of our infrastructure. > > the main reason against a common ca was, as we are really spread over > the > > world and its common to install 50+ servers in a time frame of a few > hours, > > we didn''t want to introduce any type of dependencies. > > additionally, revoking works better this way, and well... we just wanted > to > > make it work ;) > > > > Using our solution, you could also use real root CA, your company root > or > > self sign certificate, in some cases it could make sense not to use a > self > > sign if you want to reuse the certificates for Apache, ldap etc. > > > > Since all of our puppet masters are managed as well, we have one root > puppet > > master (i.e. puppet master of the puppet masters), we called it the > > puppeteer. > > the puppeteer installation is like a regular puppet master installation. > > > > We are using Apache + Mongrel: on all puppet masters you should have > > something like that in your Apache configuration (that''s just the ssl > part): > > <VirtualHost *:8140> > > SSLEngine on > > SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA > > SSLCertificateFile /var/lib/puppet/ssl/certs/your.fqdn.com.pem > > SSLCertificateKeyFile > > /var/lib/puppet/ssl/private_keys/your.fqdn.com.pem > > SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem > > SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem > > SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem > > SSLVerifyClient optional > > SSLVerifyDepth 3 > > SSLOptions +StdEnvVars > > > > RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e > > RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e > > RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e > > > > <Location /> > > > > than, let your second puppet master (the second level of the certificate > > chain) request a certificate from the puppeteer. > > > > setup an openssl.cnf file (just store it somewhere) with the following > > content (adjust for your needs): > > HOME = . > > RANDFILE = $ENV::HOME/.rnd > > [ ca ] > > default_ca = CA_default > > [ CA_default ] > > dir = /var/lib/puppet/ssl > > new_certs_dir = $dir/ca/signed > > crl_dir = $dir/ca > > database = $dir/index > > certificate = $dir/ca/ca_crt.pem > > serial = $dir/ca/serial > > crl = $dir/ca/ca_crl.pem > > private_key = $dir/ca/ca_key.pem > > RANDFILE = $dir/private/.rand > > x509_extensions = usr_cert > > unique_subject = no > > name_opt = ca_default > > cert_opt = ca_default > > default_crl_days= 30 > > default_days = 3650 > > default_md = sha1 > > preserve = no > > policy = policy_anything > > [ policy_match ] > > countryName = match > > stateOrProvinceName = match > > organizationName = match > > organizationalUnitName = optional > > commonName = supplied > > emailAddress = optional > > [ policy_anything ] > > countryName = optional > > stateOrProvinceName = optional > > localityName = optional > > organizationName = optional > > organizationalUnitName = optional > > commonName = supplied > > emailAddress = optional > > [ req ] > > default_bits = 2048 > > default_keyfile = ./ca/ca_key.pem > > default_md = sha1 > > prompt = no > > distinguished_name = root_ca_distinguished_name > > x509_extensions = v3_ca > > string_mask = nombstr > > [ root_ca_distinguished_name ] > > commonName = XXXXXXXX > > [ usr_cert ] > > basicConstraints=CA:FALSE > > subjectKeyIdentifier=hash > > authorityKeyIdentifier=keyid,issuer:always > > nsCaRevocationUrl > https://puppeteer.your.domain.com/ca_crl.pem > > [ v3_req ] > > basicConstraints = CA:FALSE > > keyUsage = nonRepudiation, digitalSignature, keyEncipherment > > [ v3_ca ] > > subjectKeyIdentifier=hash > > authorityKeyIdentifier=keyid,issuer:always > > basicConstraints = critical,CA:true > > keyUsage = keyCertSign, cRLSign > > [ crl_ext ] > > authorityKeyIdentifier=keyid:always,issuer:always > > > > on the puppetmaster: > > than copy this file to your new puppet master (e.g. /tmp) > > puppetmaster=fqdn > > /usr/bin/perl -p -i -e "s/XXXXXXXX/$puppetmaster/" /tmp/openssl.cnf > > /usr/bin/openssl req -new -nodes -key /var/lib/puppet/ssl/ca/ca_key.pem > > -config /tmp/openssl.cnf -out /tmp/${puppetmaster}.csr -passin > > file:/var/lib/puppet/ssl/ca/private/ca.pass > > copy the ${puppetmaster}:/tmp/${puppetmaster}.csr back to the > puppeteer > > > > on the puppeteer > > touch /var/lib/puppet/ssl/index > > # Sign this request with the puppeteer''s CA keys > > /usr/bin/openssl ca -config openssl.cnf -extfile openssl.cnf -extensions > > v3_ca -in ${puppetmaster}.csr -out ${puppetmaster}.pem > > -passin file:/var/lib/puppet/ssl/ca/private/ca.pass -batch > > > > # Push the new certificate into place on the puppetmaster > > scp ${puppetmaster}.pem > ${puppetmaster}:/var/lib/puppet/ssl/ca/ca_crt.pem > > > > in your installation process append the content of puppeteer > > ~puppet/ssl/ca/ca_crt.pem to /var/lib/puppet/ssl/certs/ca.pem on the > client > > > > now you should be able to use any puppet master that was signed this > way. > > > > Hopefully this helps someone, > > Ohad > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
huangmingyou
2008-May-06 04:05 UTC
[Puppet Users] Re: Certificate hierarchy - multiple puppet masters setup
Hi, ohad levy
I get some trouble when set the CA. this is my step.
ps: my ssl directory is /etc/puppet/ssl
1. rm host puppeteer.example.com ''s /etc/puppet/ssl directory
2. rm host puppetmaster1.example.com ''s /etc/puppet/ssl directory
3. rebuild the /etc/puppet/ssl directory on both host by run
/usr/bin/puppetmasterd
4.on the puppetmaster host, make puppetmaster.example.com.csr
5. copy the puppetmaster.example.com.csr and openssl.cnf to
puppeteer.example.com
6. when use the openssl.cnf in the puppeteer host, I no change anythin
in the openssl.cnf file.(error ?)
7. use puppeteer''s cert sign puppetmaster.example.csr ,get the
puppetmaster.example.com.pem.
8. on the puppetmaster host, use the puppetmaster.example.pem replace
the /etc/puppet/ssl/ca/ca_crt.pem
9. on the puppetd client,rm /etc/puppet/ssl
10.on the puppetd clien,run puppetd --test ,
11.on the puppmaster host, run puppetca -s -a
12.use puppeteer''s ca_crt.pem replace the puppetd client''s
/etc/puppet/
ssl/certs/ca.pem
13.on the puppetd client,run puppetd --test,get error like this
err: Could not retrieve configuration: Certificates were not trusted:
certificate verify failed
I''m not so clear about CA system. so please help me :p, thank you very
much.
Huang Mingyou
On May 3, 6:17 pm, "Ohad Levy" <ohadl...@gmail.com>
wrote:> Hi,
>
> you are welcome.
>
> at this point in time, we have only one server per site, with apache as a
> load balancer, so far, we didn''t need to expand to more than one
server per
> site.
> therefor, in the case of a failure, we just play around with the dns alias
> of puppet.
>
> you cannot change the hostname, as the certificate verification would fail,
> currently each site certificate would be verified, if its not fqdn,puppet
or
> puppet.domain it would fail.
>
> maybe this could be done differently, I would be really happy if pupept
> would support DNS SRV records lookup, if that would be the case, it would
be
> possible to do the balancing in the client rather on the server side.
>
> Ohad
>
> On Sat, May 3, 2008 at 2:28 PM, Jeremy Pruitt
<jeremypru...@gmail.com>
> wrote:
>
>
>
> > Thank you so much. This worked and is exactly what I''ve been
looking
> > for.
>
> > Are you doing this for failover should something happen to one of your
> > puppetmasters? If so, how do the client''s know to go to the
other
> > puppetmaster server?
>
> > Does the "server" configuration directive have a way a
accepting
> > multiple puppetmasters, or would you just change the hostname of the
> > remaining functional server to that of the missing one?
>
> > - Thanks again!!! :)
>
> > On May 1, 7:10 pm, "Ohad Levy" <ohadl...@gmail.com>
wrote:
> > > Hi,
>
> > > As some people in the list has requested, I''ll try to
describe the setup
> > we
> > > currently use with multiple puppet masters and
"HA/failover".
>
> > > I tried uploading it to the wiki, but it seems to be down at the
time of
> > > writing this page...
>
> > > As we are deploying puppet infrastructure in multiple sites it
was
> > important
> > > for us to have a centralized management for puppet, but a non
> > centralized
> > > "service", we wanted to have the option to switch
between puppet
> > masters,
> > > and did not like the idea of a single CA for all of our
infrastructure.
> > > the main reason against a common ca was, as we are really spread
over
> > the
> > > world and its common to install 50+ servers in a time frame of a
few
> > hours,
> > > we didn''t want to introduce any type of dependencies.
> > > additionally, revoking works better this way, and well... we just
wanted
> > to
> > > make it work ;)
>
> > > Using our solution, you could also use real root CA, your company
root
> > or
> > > self sign certificate, in some cases it could make sense not to
use a
> > self
> > > sign if you want to reuse the certificates for Apache, ldap etc.
>
> > > Since all of our puppet masters are managed as well, we have one
root
> > puppet
> > > master (i.e. puppet master of the puppet masters), we called it
the
> > > puppeteer.
> > > the puppeteer installation is like a regular puppet master
installation.
>
> > > We are using Apache + Mongrel: on all puppet masters you should
have
> > > something like that in your Apache configuration (that''s
just the ssl
> > part):
> > > <VirtualHost *:8140>
> > > SSLEngine on
> > > SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
> > > SSLCertificateFile
/var/lib/puppet/ssl/certs/your.fqdn.com.pem
> > > SSLCertificateKeyFile
> > > /var/lib/puppet/ssl/private_keys/your.fqdn.com.pem
> > > SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
> > > SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem
> > > SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
> > > SSLVerifyClient optional
> > > SSLVerifyDepth 3
> > > SSLOptions +StdEnvVars
>
> > > RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
> > > RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
> > > RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
>
> > > <Location />
>
> > > than, let your second puppet master (the second level of the
certificate
> > > chain) request a certificate from the puppeteer.
>
> > > setup an openssl.cnf file (just store it somewhere) with the
following
> > > content (adjust for your needs):
> > > HOME = .
> > > RANDFILE = $ENV::HOME/.rnd
> > > [ ca ]
> > > default_ca = CA_default
> > > [ CA_default ]
> > > dir = /var/lib/puppet/ssl
> > > new_certs_dir = $dir/ca/signed
> > > crl_dir = $dir/ca
> > > database = $dir/index
> > > certificate = $dir/ca/ca_crt.pem
> > > serial = $dir/ca/serial
> > > crl = $dir/ca/ca_crl.pem
> > > private_key = $dir/ca/ca_key.pem
> > > RANDFILE = $dir/private/.rand
> > > x509_extensions = usr_cert
> > > unique_subject = no
> > > name_opt = ca_default
> > > cert_opt = ca_default
> > > default_crl_days= 30
> > > default_days = 3650
> > > default_md = sha1
> > > preserve = no
> > > policy = policy_anything
> > > [ policy_match ]
> > > countryName = match
> > > stateOrProvinceName = match
> > > organizationName = match
> > > organizationalUnitName = optional
> > > commonName = supplied
> > > emailAddress = optional
> > > [ policy_anything ]
> > > countryName = optional
> > > stateOrProvinceName = optional
> > > localityName = optional
> > > organizationName = optional
> > > organizationalUnitName = optional
> > > commonName = supplied
> > > emailAddress = optional
> > > [ req ]
> > > default_bits = 2048
> > > default_keyfile = ./ca/ca_key.pem
> > > default_md = sha1
> > > prompt = no
> > > distinguished_name = root_ca_distinguished_name
> > > x509_extensions = v3_ca
> > > string_mask = nombstr
> > > [ root_ca_distinguished_name ]
> > > commonName = XXXXXXXX
> > > [ usr_cert ]
> > > basicConstraints=CA:FALSE
> > > subjectKeyIdentifier=hash
> > > authorityKeyIdentifier=keyid,issuer:always
> > > nsCaRevocationUrl >
>https://puppeteer.your.domain.com/ca_crl.pem
> > > [ v3_req ]
> > > basicConstraints = CA:FALSE
> > > keyUsage = nonRepudiation, digitalSignature, keyEncipherment
> > > [ v3_ca ]
> > > subjectKeyIdentifier=hash
> > > authorityKeyIdentifier=keyid,issuer:always
> > > basicConstraints = critical,CA:true
> > > keyUsage = keyCertSign, cRLSign
> > > [ crl_ext ]
> > > authorityKeyIdentifier=keyid:always,issuer:always
>
> > > on the puppetmaster:
> > > than copy this file to your new puppet master (e.g. /tmp)
> > > puppetmaster=fqdn
> > > /usr/bin/perl -p -i -e "s/XXXXXXXX/$puppetmaster/"
/tmp/openssl.cnf
> > > /usr/bin/openssl req -new -nodes -key
/var/lib/puppet/ssl/ca/ca_key.pem
> > > -config /tmp/openssl.cnf -out /tmp/${puppetmaster}.csr -passin
> > > file:/var/lib/puppet/ssl/ca/private/ca.pass
> > > copy the ${puppetmaster}:/tmp/${puppetmaster}.csr back to the
> > puppeteer
>
> > > on the puppeteer
> > > touch /var/lib/puppet/ssl/index
> > > # Sign this request with the puppeteer''s CA keys
> > > /usr/bin/openssl ca -config openssl.cnf -extfile openssl.cnf
-extensions
> > > v3_ca -in ${puppetmaster}.csr -out ${puppetmaster}.pem
> > > -passin file:/var/lib/puppet/ssl/ca/private/ca.pass -batch
>
> > > # Push the new certificate into place on the puppetmaster
> > > scp ${puppetmaster}.pem
> > ${puppetmaster}:/var/lib/puppet/ssl/ca/ca_crt.pem
>
> > > in your installation process append the content of puppeteer
> > > ~puppet/ssl/ca/ca_crt.pem to /var/lib/puppet/ssl/certs/ca.pem on
the
> > client
>
> > > now you should be able to use any puppet master that was signed
this
> > way.
>
> > > Hopefully this helps someone,
> > > Ohad
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---