Puppet users - Feb 2013 - How to manually create Puppet CA and client certificates using openssl?

I am wondering how to manually (using openssl instead of puppet cert 
command) create CA that would be usable by Puppet? The goal would be to 
script creation of such CA''s to deploy them on multiple puppetmasters, 
instead of certificates being created on them via puppet cert command.

Any ideas on how to do it? I was only able to find something like that:
https://wiki.mozilla.org/ReleaseEngineering/PuppetAgain/HowTo/Set_up_a_standalone_puppetmasterbut
it fails to work - after creating CA and client cert and applying them to 
puppetmaster, it complains with:

Feb 16 09:35:20 test puppet-master[81728]: Could not prepare for execution: The
certificate retrieved from the master does not match the agent''s
private key.
Feb 16 09:35:20 test puppet-master[81728]: Certificate fingerprint:
4F:08:AE:01:B9:14:AC:A4:EA:A7:92:D7:02:E9:34:39:1C:5F:0D:93:A0:85:1C:CF:68:E4:52:B8:25:D1:11:64
Feb 16 09:35:20 test puppet-master[81728]: To fix this, remove the certificate
from both the master and the agent and then start a puppet run, which will
automatically regenerate a certficate.
Feb 16 09:35:20 test puppet-master[81728]: On the master:
Feb 16 09:35:20 test puppet-master[81728]:   puppet cert clean test
Feb 16 09:35:20 test puppet-master[81728]: On the agent:
Feb 16 09:35:20 test puppet-master[81728]:   rm -f
/var/puppet/ssl/certs/test.pem
Feb 16 09:35:20 test puppet-master[81728]:   puppet agent -t

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

Bumping - no one knows if its possible or isnt it possible at all?

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

On 02/16/2013 12:20 PM, spankthespam@gmail.com wrote:
> after creating CA and client cert and applying them to puppetmaster, it
> complains with:
Wait, what? You create a new CA, even after agents have already been
certified, then create new agent certificates?

If your CA changes, you will have to terminate all the (now deprecated)
agent certificates and sign new certificates for all agents.

Basically, I would expect the outcome you are observing, and you should
just follow the instructions given in your log excerpt. Note that you
are *not* supposed to remove the CA from the master, only the copy of
the agent''s certificate.

HTH,
Felix

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

Dear Felix,

I think you''re getting it wrong, let me clarify it a bit. The goal of
this
is to be able to write web interface for generating puppetmasters CA''s
and
client certificates on demand. An example: install 3 puppetmasters with 
loadbalancer in front. Use web interface to generate CA and certificates 
for chosen clients (lets say, 10 machines). Deploy such generated CA''s
on
puppetmasters, and relevant bits on puppet clients to authorize them 
against these puppetmasters. Whenever there''s need for change, use that
CA
via web interface to add and delete client certificates, redeploy them on 
puppetmasters and so on. This, while doable via Subprocess functions 
(Python is the language of choice for me, but that doesnt really matters) 
and calls to relevant puppet system commands is extremely ugly and not 
flexible solution. I would love to do it via openssl library, but to do so, 
I''d need to have a workable way to build CA''s and sign (and
revoke) client
certs via openssl command - so far I cant reach that goal. I hope this 
makes more sense now.

Regards,
S.

On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank
wrote:
>
> On 02/16/2013 12:20 PM, spankt...@gmail.com <javascript:> wrote: 
> > after creating CA and client cert and applying them to puppetmaster,
it
> > complains with: 
>
> Wait, what? You create a new CA, even after agents have already been 
> certified, then create new agent certificates? 
>
> If your CA changes, you will have to terminate all the (now deprecated) 
> agent certificates and sign new certificates for all agents. 
>
> Basically, I would expect the outcome you are observing, and you should 
> just follow the instructions given in your log excerpt. Note that you 
> are *not* supposed to remove the CA from the master, only the copy of 
> the agent''s certificate. 
>
> HTH, 
> Felix 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

You might have better luck using something like FreeIPA and using it''s
ca
cert and setting up certs for each node and using those as the puppet certs.

This may help.
http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/

I had a go at setting it up but I am using FreeIPA 3 and the steps need
some changing for that so your mileage may vary.


On 20 February 2013 06:15, <spankthespam@gmail.com> wrote:
> Dear Felix,
>
> I think you''re getting it wrong, let me clarify it a bit. The goal
of this
> is to be able to write web interface for generating puppetmasters
CA''s and
> client certificates on demand. An example: install 3 puppetmasters with
> loadbalancer in front. Use web interface to generate CA and certificates
> for chosen clients (lets say, 10 machines). Deploy such generated
CA''s on
> puppetmasters, and relevant bits on puppet clients to authorize them
> against these puppetmasters. Whenever there''s need for change, use
that CA
> via web interface to add and delete client certificates, redeploy them on
> puppetmasters and so on. This, while doable via Subprocess functions
> (Python is the language of choice for me, but that doesnt really matters)
> and calls to relevant puppet system commands is extremely ugly and not
> flexible solution. I would love to do it via openssl library, but to do so,
> I''d need to have a workable way to build CA''s and sign
(and revoke) client
> certs via openssl command - so far I cant reach that goal. I hope this
> makes more sense now.
>
> Regards,
> S.
>
> On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
>
>> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote:
>> > after creating CA and client cert and applying them to
puppetmaster, it
>> > complains with:
>>
>> Wait, what? You create a new CA, even after agents have already been
>> certified, then create new agent certificates?
>>
>> If your CA changes, you will have to terminate all the (now deprecated)
>> agent certificates and sign new certificates for all agents.
>>
>> Basically, I would expect the outcome you are observing, and you should
>> just follow the instructions given in your log excerpt. Note that you
>> are *not* supposed to remove the CA from the master, only the copy of
>> the agent''s certificate.
>>
>> HTH,
>> Felix
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks Pete, but unfortunately that wont work. The nodes are out of my 
control, and all I can do is to provide their owners client certs via web 
gui. In addition to that, I would need multiple CA''s, as the clients
(and
puppetmasters) would be destinated for different owners, and they shouldnt 
share the CA.

On Wednesday, February 20, 2013 2:15:33 AM UTC, Pete
wrote:
>
> You might have better luck using something like FreeIPA and using
it''s ca
> cert and setting up certs for each node and using those as the puppet
certs.
>
> This may help.
> http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/
>
> I had a go at setting it up but I am using FreeIPA 3 and the steps need 
> some changing for that so your mileage may vary.
>
>
> On 20 February 2013 06:15, <spankt...@gmail.com <javascript:>>
wrote:
>
>> Dear Felix,
>>
>> I think you''re getting it wrong, let me clarify it a bit. The
goal of
>> this is to be able to write web interface for generating puppetmasters
CA''s
>> and client certificates on demand. An example: install 3 puppetmasters
with
>> loadbalancer in front. Use web interface to generate CA and
certificates
>> for chosen clients (lets say, 10 machines). Deploy such generated
CA''s on
>> puppetmasters, and relevant bits on puppet clients to authorize them 
>> against these puppetmasters. Whenever there''s need for change,
use that CA
>> via web interface to add and delete client certificates, redeploy them
on
>> puppetmasters and so on. This, while doable via Subprocess functions 
>> (Python is the language of choice for me, but that doesnt really
matters)
>> and calls to relevant puppet system commands is extremely ugly and not 
>> flexible solution. I would love to do it via openssl library, but to do
so,
>> I''d need to have a workable way to build CA''s and
sign (and revoke) client
>> certs via openssl command - so far I cant reach that goal. I hope this 
>> makes more sense now.
>>
>> Regards,
>> S.
>>
>> On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
>>
>>> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote: 
>>> > after creating CA and client cert and applying them to
puppetmaster,
>>> it 
>>> > complains with: 
>>>
>>> Wait, what? You create a new CA, even after agents have already
been
>>> certified, then create new agent certificates? 
>>>
>>> If your CA changes, you will have to terminate all the (now
deprecated)
>>> agent certificates and sign new certificates for all agents. 
>>>
>>> Basically, I would expect the outcome you are observing, and you
should
>>> just follow the instructions given in your log excerpt. Note that
you
>>> are *not* supposed to remove the CA from the master, only the copy
of
>>> the agent''s certificate. 
>>>
>>> HTH, 
>>> Felix 
>>>
>>  -- 
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to puppet-users...@googlegroups.com <javascript:>.
>> To post to this group, send email to
puppet...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hi,

I think I understood your goal well enough, and it''s sound in and of
itself, but I believe you have some misconceptions on how to implement this.

First off, so we''re on the same page: The CA is your root certificate.
It''s a self signed certificate shared by all masters. Only the masters
have its private key. They use it to sign all other puppet related
certificates.

A client certificate is generated by a master based on the CA and a
certificate signing request from the agent. It''s necessary to either
a) have the CSR generated agent side, so the agent has the private key
generated itself or
b) do all the generating master side and implement a secure way to push
the agent''s private key to the agent

Let''s cut right to the bottom line: You do *not* want to create new
CAs,
ever. You make a CA, make sure its private key is well protected, and
stick with that. If you need deploy aditional masters at various times,
you need a process that will supply them with the CA and its key.

I''m not sure wether you can separate the puppet master from the puppet
ca network-wise, but if it''s possible, it would be infinitely simpler
to
stick to a monolithic ca server and do only the other agent/master
interaction through loadbalancing.

I believe that your core problem at the moment is private key
management, but that''s only a guess.

On 02/19/2013 09:15 PM, spankthespam@gmail.com wrote:
> Dear Felix,
> 
> I think you''re getting it wrong, let me clarify it a bit. The goal
of
> this is to be able to write web interface for generating puppetmasters
> CA''s and client certificates on demand. An example: install 3
> puppetmasters with loadbalancer in front. Use web interface to generate
> CA and certificates for chosen clients (lets say, 10 machines). Deploy
> such generated CA''s on puppetmasters, and relevant bits on puppet
> clients to authorize them against these puppetmasters. Whenever
there''s
> need for change, use that CA via web interface to add and delete client
> certificates, redeploy them on puppetmasters and so on. This, while
> doable via Subprocess functions (Python is the language of choice for
> me, but that doesnt really matters) and calls to relevant puppet system
> commands is extremely ugly and not flexible solution. I would love to do
> it via openssl library, but to do so, I''d need to have a workable
way to
> build CA''s and sign (and revoke) client certs via openssl command
- so
> far I cant reach that goal. I hope this makes more sense now.
> 
> Regards,
> S.
> 
> On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
> 
>     On 02/16/2013 12:20 PM, spankt...@gmail.com <javascript:> wrote:
>     > after creating CA and client cert and applying them to
>     puppetmaster, it
>     > complains with:
> 
>     Wait, what? You create a new CA, even after agents have already been
>     certified, then create new agent certificates?
> 
>     If your CA changes, you will have to terminate all the (now deprecated)
>     agent certificates and sign new certificates for all agents.
> 
>     Basically, I would expect the outcome you are observing, and you should
>     just follow the instructions given in your log excerpt. Note that you
>     are *not* supposed to remove the CA from the master, only the copy of
>     the agent''s certificate. 
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Dear Felix,

On Wednesday, February 20, 2013 9:58:45 AM UTC, Felix.Frank
wrote:
>
> Hi, 
>
> I think I understood your goal well enough, and it''s sound in and
of
> itself, but I believe you have some misconceptions on how to implement 
> this. 
>
> First off, so we''re on the same page: The CA is your root
certificate.
> It''s a self signed certificate shared by all masters. Only the
masters
> have its private key. They use it to sign all other puppet related 
> certificates. 
>
Correct.
 
>
> A client certificate is generated by a master based on the CA and a 
> certificate signing request from the agent. It''s necessary to
either
> a) have the CSR generated agent side, so the agent has the private key 
> generated itself or 
> b) do all the generating master side and implement a secure way to push 
> the agent''s private key to the agent 
>
The b) is the goal here, correct.
 
>
> Let''s cut right to the bottom line: You do *not* want to create
new CAs,
> ever. You make a CA, make sure its private key is well protected, and 
> stick with that. If you need deploy aditional masters at various times, 
> you need a process that will supply them with the CA and its key. 
>
Incorrect. You *do* want to create new CA''s. What about different 
puppetmasters pools? Imagine you and me, we both want a puppetmasters setup 
with LB''s in front of them, for our own machines, and we''d
rather want to
have different CA''s for our puppetmasters.
 
>
> I''m not sure wether you can separate the puppet master from the
puppet
> ca network-wise, but if it''s possible, it would be infinitely
simpler to
> stick to a monolithic ca server and do only the other agent/master 
> interaction through loadbalancing. 
>
Dont worry about the details of separation network wise or any other. All I 
want to do, is to generate complete CA and client certs programatically, 
using openssl lib - how they''re going to be deployed on puppetmasters
and
puppet clients is out of scope here - it can be via rsync, it can be by 
embedding CA''s into vm images per client base, it can be done in many 
different ways. A monolithic CA server is out of question, as it becomes a 
spof.
 
>
> I believe that your core problem at the moment is private key 
> management, but that''s only a guess. 
>
Incorrect, the problem is to emulate puppet ca/cert behavior using openssl 
command (and then by openssl lib).
 
>
> On 02/19/2013 09:15 PM, spankt...@gmail.com <javascript:> wrote: 
> > Dear Felix, 
> > 
> > I think you''re getting it wrong, let me clarify it a bit. The
goal of
> > this is to be able to write web interface for generating puppetmasters
> > CA''s and client certificates on demand. An example: install 3
> > puppetmasters with loadbalancer in front. Use web interface to
generate
> > CA and certificates for chosen clients (lets say, 10 machines). Deploy
> > such generated CA''s on puppetmasters, and relevant bits on
puppet
> > clients to authorize them against these puppetmasters. Whenever
there''s
> > need for change, use that CA via web interface to add and delete
client
> > certificates, redeploy them on puppetmasters and so on. This, while 
> > doable via Subprocess functions (Python is the language of choice for 
> > me, but that doesnt really matters) and calls to relevant puppet
system
> > commands is extremely ugly and not flexible solution. I would love to
do
> > it via openssl library, but to do so, I''d need to have a
workable way to
> > build CA''s and sign (and revoke) client certs via openssl
command - so
> > far I cant reach that goal. I hope this makes more sense now. 
> > 
> > Regards, 
> > S. 
> > 
> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote: 
> > 
> >     On 02/16/2013 12:20 PM, spankt...@gmail.com <javascript:>
wrote:
> >     > after creating CA and client cert and applying them to 
> >     puppetmaster, it 
> >     > complains with: 
> > 
> >     Wait, what? You create a new CA, even after agents have already
been
> >     certified, then create new agent certificates? 
> > 
> >     If your CA changes, you will have to terminate all the (now 
> deprecated) 
> >     agent certificates and sign new certificates for all agents. 
> > 
> >     Basically, I would expect the outcome you are observing, and you 
> should 
> >     just follow the instructions given in your log excerpt. Note that 
> you 
> >     are *not* supposed to remove the CA from the master, only the copy
> of 
> >     the agent''s certificate. 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On 02/20/2013 11:37 AM, spankthespam@gmail.com wrote:
> Incorrect. You *do* want to create new CA''s. What about different
> puppetmasters pools? Imagine you and me, we both want a puppetmasters
> setup with LB''s in front of them, for our own machines, and
we''d rather
> want to have different CA''s for our puppetmasters.
Well, so you''d want *your* agents to receive catalogs from *my* puppet
masters?

That''s a whole different problem altogether. Each agent node will need
to run several agents, each with their own view of what the CA and the
master certificate is. They could share the agent''s private key, but
that would actually add complexity.

Basically, you probably want separate /var/lib/puppet instances on the
agents for each "master pool".
> it can be via rsync
Oh, please don''t.
> monolithic CA server is out of question, as it becomes a spof.
Not really, the ca service should not see much use during day-to-day
operation, but again, I may be wrong about this.
> Incorrect, the problem is to emulate puppet ca/cert behavior using
> openssl command (and then by openssl lib).
Ah, only you aren''t. The puppet ca service works under the premise that
the client simply generates a CSR for itself and forwards that to the
puppet ca service.

Have you had any success signing the certificate using openssl, when the
CSR originates with the agent (so, as a start, you do step 2 your way?)
Once you have that working, all that''s left to do is doing the CSR
generation using openssl, which shouldn''t be that hard, either.
What''s
hard is not doing it on the agent node.

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

Dear Felix,

On Wednesday, February 20, 2013 10:51:50 AM UTC, Felix.Frank
wrote:
>
> On 02/20/2013 11:37 AM, spankt...@gmail.com <javascript:> wrote: 
> > Incorrect. You *do* want to create new CA''s. What about
different
> > puppetmasters pools? Imagine you and me, we both want a puppetmasters 
> > setup with LB''s in front of them, for our own machines, and
we''d rather
> > want to have different CA''s for our puppetmasters. 
>
> Well, so you''d want *your* agents to receive catalogs from *my*
puppet
> masters? 
>
No, absolutely not. I need a piece of web based software that would allow 
you and me generate our own CA''s for out own, separate puppetmaster 
clusters and client certs signed using these CA''s. Your CA would be for
your puppetmasters and clients only, mine would be for mines. And someone 
elses would be for him exclusively. The only thing common between your, 
mine and everyone''s else CA''s and certs would be the fact they
were created
and provided by that software.
 
>
> That''s a whole different problem altogether. Each agent node will
need
> to run several agents, each with their own view of what the CA and the 
> master certificate is. They could share the agent''s private key,
but
> that would actually add complexity. 
>
> Basically, you probably want separate /var/lib/puppet instances on the 
> agents for each "master pool". 
>
> > it can be via rsync 
>
> Oh, please don''t. 
>
If the rsync uses SSH for communication, what''s wrong with it? And
beside,
this was only an example, the CA''s and certs could be stored in DB,
could
be encrypted with PGP, possibilities are endless.
 
>
> > monolithic CA server is out of question, as it becomes a spof. 
>
> Not really, the ca service should not see much use during day-to-day 
> operation, but again, I may be wrong about this. 
>
Regardless of how much use it has, it is a spof. Once it''s down, whole 
cluster malfunctiones. With monolithic CA server down, all clusters are 
malfunctioning.
 
>
> > Incorrect, the problem is to emulate puppet ca/cert behavior using 
> > openssl command (and then by openssl lib). 
>
> Ah, only you aren''t. The puppet ca service works under the premise
that
> the client simply generates a CSR for itself and forwards that to the 
> puppet ca service. 
>
> Have you had any success signing the certificate using openssl, when the 
> CSR originates with the agent (so, as a start, you do step 2 your way?) 
> Once you have that working, all that''s left to do is doing the CSR
> generation using openssl, which shouldn''t be that hard, either.
What''s
> hard is not doing it on the agent node. 
>
No, so far I''ve complete failure. I tried to do it the Mozilla way,
from
the link included in original post, but it fails and I cant find out why. 

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

On 02/20/2013 12:02 PM, spankthespam@gmail.com wrote:
> 
> Regardless of how much use it has, it is a spof. Once it''s down,
whole
> cluster malfunctiones. With monolithic CA server down, all clusters are
> malfunctioning.
I disagree. An SSL connection requires two peers and at least one signed
certificate. The client needs to trust the issuer''s certificate, but it
needs not contact a ca server to re-validate that certificate for each
connection.

A downtime of the CA service would merely imply that you cannot sign any
new certificates for the time being.
>     Have you had any success signing the certificate using openssl, when
>     the
>     CSR originates with the agent (so, as a start, you do step 2 your way?)
>     Once you have that working, all that''s left to do is doing the
CSR
>     generation using openssl, which shouldn''t be that hard,
either. What''s
>     hard is not doing it on the agent node.
> 
> 
> No, so far I''ve complete failure. I tried to do it the Mozilla
way, from
> the link included in original post, but it fails and I cant find out why. 
I only just looked at that. Lots of script work I won''t dive into.

I advise to do this bottom up:

1. Set up a plain old puppet master the usual way, make it work with an
agent

2. Once that works, add another agent, but don''t "puppet ca
sign" its
certificate but instead use an openssl invocation. Place the signed
certificate in the appropriate location on the master host. The agent
should receive it during its next connection.

3. Once that works, generate a CSR on yet a new agent using openssl, put
the files in the appropriate locations in /var/lib/puppet/ssl and do an
agent run. It should send your CSR to the master. Repeat step 2.

4. Once that works, you''re basically there. Doing step 3 on the master
node and transferring the files should not be too different.

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

On Wednesday, February 20, 2013 12:00:07 PM UTC, Felix.Frank
wrote:
>
> On 02/20/2013 12:02 PM, spankt...@gmail.com <javascript:> wrote: 
> > 
> > Regardless of how much use it has, it is a spof. Once it''s
down, whole
> > cluster malfunctiones. With monolithic CA server down, all clusters
are
> > malfunctioning. 
>
> I disagree. An SSL connection requires two peers and at least one signed 
> certificate. The client needs to trust the issuer''s certificate,
but it
> needs not contact a ca server to re-validate that certificate for each 
> connection. 
>
> A downtime of the CA service would merely imply that you cannot sign any 
> new certificates for the time being. 
>
And that''s already too much. The whole point of this is to avoid
spof''s of
any kind and be able to create redundant, highly available Puppet 
infrastructure. Unfortunately, I cant accept single CA server.
 
>
> >     Have you had any success signing the certificate using openssl,
when
> >     the 
> >     CSR originates with the agent (so, as a start, you do step 2 your 
> way?) 
> >     Once you have that working, all that''s left to do is
doing the CSR
> >     generation using openssl, which shouldn''t be that hard,
either.
> What''s 
> >     hard is not doing it on the agent node. 
> > 
> > 
> > No, so far I''ve complete failure. I tried to do it the
Mozilla way, from
> > the link included in original post, but it fails and I cant find out 
> why. 
>
> I only just looked at that. Lots of script work I won''t dive into.
>
> I advise to do this bottom up: 
>
> 1. Set up a plain old puppet master the usual way, make it work with an 
> agent 
>
> 2. Once that works, add another agent, but don''t "puppet ca
sign" its
> certificate but instead use an openssl invocation. Place the signed 
> certificate in the appropriate location on the master host. The agent 
> should receive it during its next connection. 
>
> 3. Once that works, generate a CSR on yet a new agent using openssl, put 
> the files in the appropriate locations in /var/lib/puppet/ssl and do an 
> agent run. It should send your CSR to the master. Repeat step 2. 
>
> 4. Once that works, you''re basically there. Doing step 3 on the
master
> node and transferring the files should not be too different. 
>
And what would be the purpose of that? That still includes using puppet to 
create CA, and I want to avoid that completely. What the ideal workflow 
would like is:

1. Puppetmaster''s vm''s are being booted. No CA nor cert
actions taken.

2. User goes to web app, click''s ''generate CA'' - CA
gets generated.

3. User provides node names to generate - CA generated in 2. is being used 
to generate and sign these.

4. User downloads all files neccessary to place on his puppet nodes.

5. CA and client certs are being placed on vm''s booted in 1.

6. User can now use his nodes without any certificate actions required to 
talk to puppetmasters behind the loadbalancer. 

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

On 02/20/2013 01:28 PM, spankthespam@gmail.com wrote:
> And what would be the purpose of that? That still includes using puppet
> to create CA, and I want to avoid that completely.
Ah, right. I forgot step 5. Which is replacing the CA with one created
using openssl. Of course, all other certs are obsolete after you do
that, so you can use your shiny new process of certifying agents to make
them new ones.
> 1. Puppetmaster''s vm''s are being booted. No CA nor cert
actions taken.
>
> 2. User goes to web app, click''s ''generate CA'' -
CA gets generated.
A simpler alternative might be:
1a. User creates puppetmaster vm for a new pool, that bootstraps itself
with a CA certificate
1b. User adds a puppetmaster vm to an existing pool, by cloning another VM

That way, you need not even implement a frontend for generating CAs on
the fly.

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

Hi again,

to answer the question more succinctly: The purpose of the proposed
process is to find and eliminate the points of failure.

Once you''ve completed all those iterations, you will very well know
what
works and how.

Cheers,
Felix

On 02/20/2013 01:58 PM, Felix Frank wrote:
>> And what would be the purpose of that? That still includes using puppet
>> > to create CA, and I want to avoid that completely.
> Ah, right. I forgot step 5. Which is replacing the CA with one created
> using openssl. Of course, all other certs are obsolete after you do
> that, so you can use your shiny new process of certifying agents to make
> them new ones.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, February 20, 2013 12:58:44 PM UTC, Felix.Frank
wrote:
>
> On 02/20/2013 01:28 PM, spankt...@gmail.com <javascript:> wrote: 
> > And what would be the purpose of that? That still includes using
puppet
> > to create CA, and I want to avoid that completely. 
>
> Ah, right. I forgot step 5. Which is replacing the CA with one created 
> using openssl. Of course, all other certs are obsolete after you do 
> that, so you can use your shiny new process of certifying agents to make 
> them new ones. 
>
Great, except I tried that and failed, therefore this thread ;) I was 
hoping someone was doing something like that already and know if its 
possible, and if it is, how to do it properly.
 
>
> > 1. Puppetmaster''s vm''s are being booted. No CA nor
cert actions taken.
> > 
> > 2. User goes to web app, click''s ''generate
CA'' - CA gets generated.
>
> A simpler alternative might be: 
> 1a. User creates puppetmaster vm for a new pool, that bootstraps itself 
> with a CA certificate 
> 1b. User adds a puppetmaster vm to an existing pool, by cloning another VM 
>
> That way, you need not even implement a frontend for generating CAs on 
> the fly. 
>
That''s an interesting and tempting perspective, although I have two
issues
with it:

a) it would require user to know what is he doing with puppet ca/certs, and 
one of the purposes of the web app is to make user''s life, and entire 
process as easy as possible
b) I would lost control over how many nodes user could add using that CA, 
something that would have been applied in the application logic

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

On 02/20/2013 02:38 PM, spankthespam@gmail.com wrote:
>     Ah, right. I forgot step 5. Which is replacing the CA with one created
>     using openssl. Of course, all other certs are obsolete after you do
>     that, so you can use your shiny new process of certifying agents to
>     make
>     them new ones.
> 
> 
> Great, except I tried that and failed, therefore this thread ;) I was
> hoping someone was doing something like that already and know if its
> possible, and if it is, how to do it properly.
Well, I disbelieve this has been done, because the way you are proposing
to model puppet architecture sounds pretty unique.

As I understood, you tried to do steps 1 through 5 in one, which failed.
I can think of quite some ways this would happen. Therefor the baby steps.

HTH,
Felix

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

Howdy!

I might suggest starting here:

http://projects.puppetlabs.com/projects/1/wiki/certificates_and_security


It talks a little about setting up a seperate CA - this is pretty 
commonly done for HA environments.

As far as pre-generating the client certs without Puppet, I''d have a 
look at ssl/host.rb in the source tree to see how it does it.  It has 
all the logic puppet certificate --generate uses (It seems to call 
generate_certificate_request), and then the logic --sign uses which 
calls ca.sign.  If you look through that code I''m sure you can figure 
out the right options to pass openssl to do it.

Jason

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

I think you''re trying to over complicate the situation here.

Yes its a single point of failure but unfortunately that is not going
to change anytime between now and maybe 6 months.

You do not need multiple CAs to use multiple puppet masters. The
client needs to have the setting ca_server set to the Puppet Master
that is the CA. You need to configure that Puppet master with ca true. The
puppet masters you create need to be configured with ca false. You can have 300
different puppet masters and each client can
connect to the different ones as needed.

If you need to limit which clients can connect to which puppet masters
then you should look at the auth.conf file.

As for a web interface around certificate signing, when each client
connects into the CA it will submit its request and if autosign is
turned off it should be setup to wait for certificate. The web
interface can be a wrapper around the puppet cert face so you can get
a list of certificates signed and whats waiting to be signed. You can
even set it up to revoke or clean out a certificate. You do not need
to call to the command line to do this either, you can interface with
the puppet api from rubygems.


On Tue, Feb 19, 2013 at 3:15 PM,  <spankthespam@gmail.com>
wrote:
> Dear Felix,
>
> I think you''re getting it wrong, let me clarify it a bit. The goal
of this
> is to be able to write web interface for generating puppetmasters
CA''s and
> client certificates on demand. An example: install 3 puppetmasters with
> loadbalancer in front. Use web interface to generate CA and certificates
for
> chosen clients (lets say, 10 machines). Deploy such generated CA''s
on
> puppetmasters, and relevant bits on puppet clients to authorize them
against
> these puppetmasters. Whenever there''s need for change, use that CA
via web
> interface to add and delete client certificates, redeploy them on
> puppetmasters and so on. This, while doable via Subprocess functions
(Python
> is the language of choice for me, but that doesnt really matters) and calls
> to relevant puppet system commands is extremely ugly and not flexible
> solution. I would love to do it via openssl library, but to do so,
I''d need
> to have a workable way to build CA''s and sign (and revoke) client
certs via
> openssl command - so far I cant reach that goal. I hope this makes more
> sense now.
>
> Regards,
> S.
>
> On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
>>
>> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote:
>> > after creating CA and client cert and applying them to
puppetmaster, it
>> > complains with:
>>
>> Wait, what? You create a new CA, even after agents have already been
>> certified, then create new agent certificates?
>>
>> If your CA changes, you will have to terminate all the (now deprecated)
>> agent certificates and sign new certificates for all agents.
>>
>> Basically, I would expect the outcome you are observing, and you should
>> just follow the instructions given in your log excerpt. Note that you
>> are *not* supposed to remove the CA from the master, only the copy of
>> the agent''s certificate.
>>
>> HTH,
>> Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Dear Matt,

On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt
wrote:
>
> I think you''re trying to over complicate the situation here. 
>
> Yes its a single point of failure but unfortunately that is not going 
> to change anytime between now and maybe 6 months.
>
I am aware of that, and I am fine with that.
 
>
> You do not need multiple CAs to use multiple puppet masters. The 
> client needs to have the setting ca_server set to the Puppet Master 
> that is the CA. You need to configure that Puppet master with ca = 
> true. The puppet masters you create need to be configured with ca = 
> false. You can have 300 different puppet masters and each client can 
> connect to the different ones as needed. 
>
The thing is, the puppetmasters are exposed to puppet clients via 
loadbalancer, so they actually appear as one puppetmaster, therefore, they 
all need to have the same CA installed.
 
>
> If you need to limit which clients can connect to which puppet masters 
> then you should look at the auth.conf file. 
>
> As for a web interface around certificate signing, when each client 
> connects into the CA it will submit its request and if autosign is 
> turned off it should be setup to wait for certificate. The web 
> interface can be a wrapper around the puppet cert face so you can get 
> a list of certificates signed and whats waiting to be signed. You can 
> even set it up to revoke or clean out a certificate. You do not need 
> to call to the command line to do this either, you can interface with 
> the puppet api from rubygems. 
>
That, again, would require running puppetmaster per user, something I 
really, really want to avoid.
 
>
>
> On Tue, Feb 19, 2013 at 3:15 PM,  <spankt...@gmail.com
<javascript:>>
> wrote: 
> > Dear Felix, 
> > 
> > I think you''re getting it wrong, let me clarify it a bit. The
goal of
> this 
> > is to be able to write web interface for generating puppetmasters
CA''s
> and 
> > client certificates on demand. An example: install 3 puppetmasters
with
> > loadbalancer in front. Use web interface to generate CA and
certificates
> for 
> > chosen clients (lets say, 10 machines). Deploy such generated
CA''s on
> > puppetmasters, and relevant bits on puppet clients to authorize them 
> against 
> > these puppetmasters. Whenever there''s need for change, use
that CA via
> web 
> > interface to add and delete client certificates, redeploy them on 
> > puppetmasters and so on. This, while doable via Subprocess functions 
> (Python 
> > is the language of choice for me, but that doesnt really matters) and 
> calls 
> > to relevant puppet system commands is extremely ugly and not flexible 
> > solution. I would love to do it via openssl library, but to do so,
I''d
> need 
> > to have a workable way to build CA''s and sign (and revoke)
client certs
> via 
> > openssl command - so far I cant reach that goal. I hope this makes
more
> > sense now. 
> > 
> > Regards, 
> > S. 
> > 
> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote: 
> >> 
> >> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote: 
> >> > after creating CA and client cert and applying them to
puppetmaster,
> it 
> >> > complains with: 
> >> 
> >> Wait, what? You create a new CA, even after agents have already
been
> >> certified, then create new agent certificates? 
> >> 
> >> If your CA changes, you will have to terminate all the (now
deprecated)
> >> agent certificates and sign new certificates for all agents. 
> >> 
> >> Basically, I would expect the outcome you are observing, and you
should
> >> just follow the instructions given in your log excerpt. Note that
you
> >> are *not* supposed to remove the CA from the master, only the copy
of
> >> the agent''s certificate. 
> >> 
> >> HTH, 
> >> Felix 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send
> an 
> > email to puppet-users...@googlegroups.com <javascript:>. 
> > To post to this group, send email to
puppet...@googlegroups.com<javascript:>.
>
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

I run an F5 load balancer with SSL termination at the F5 and I dont
need to put the CA cert anywhere except the F5. The actual CA signs
the certs. The CA cert is only really used to authenticate the client
cert. This gives the appearance to my puppet clients that I only have
one puppet master when in actuality I have around 4-5 per VIP.

As for your last part I''m not really seeing how you think you would
need a puppetmaster per user.

On Wed, Feb 20, 2013 at 2:59 PM,  <spankthespam@gmail.com>
wrote:
> Dear Matt,
>
>
> On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote:
>>
>> I think you''re trying to over complicate the situation here.
>>
>> Yes its a single point of failure but unfortunately that is not going
>> to change anytime between now and maybe 6 months.
>
>
> I am aware of that, and I am fine with that.
>
>>
>>
>> You do not need multiple CAs to use multiple puppet masters. The
>> client needs to have the setting ca_server set to the Puppet Master
>> that is the CA. You need to configure that Puppet master with ca
>> true. The puppet masters you create need to be configured with ca
>> false. You can have 300 different puppet masters and each client can
>> connect to the different ones as needed.
>
>
> The thing is, the puppetmasters are exposed to puppet clients via
> loadbalancer, so they actually appear as one puppetmaster, therefore, they
> all need to have the same CA installed.
>
>>
>>
>> If you need to limit which clients can connect to which puppet masters
>> then you should look at the auth.conf file.
>>
>> As for a web interface around certificate signing, when each client
>> connects into the CA it will submit its request and if autosign is
>> turned off it should be setup to wait for certificate. The web
>> interface can be a wrapper around the puppet cert face so you can get
>> a list of certificates signed and whats waiting to be signed. You can
>> even set it up to revoke or clean out a certificate. You do not need
>> to call to the command line to do this either, you can interface with
>> the puppet api from rubygems.
>
>
> That, again, would require running puppetmaster per user, something I
> really, really want to avoid.
>
>>
>>
>>
>> On Tue, Feb 19, 2013 at 3:15 PM,  <spankt...@gmail.com> wrote:
>> > Dear Felix,
>> >
>> > I think you''re getting it wrong, let me clarify it a bit.
The goal of
>> > this
>> > is to be able to write web interface for generating puppetmasters
CA''s
>> > and
>> > client certificates on demand. An example: install 3 puppetmasters
with
>> > loadbalancer in front. Use web interface to generate CA and
certificates
>> > for
>> > chosen clients (lets say, 10 machines). Deploy such generated
CA''s on
>> > puppetmasters, and relevant bits on puppet clients to authorize
them
>> > against
>> > these puppetmasters. Whenever there''s need for change,
use that CA via
>> > web
>> > interface to add and delete client certificates, redeploy them on
>> > puppetmasters and so on. This, while doable via Subprocess
functions
>> > (Python
>> > is the language of choice for me, but that doesnt really matters)
and
>> > calls
>> > to relevant puppet system commands is extremely ugly and not
flexible
>> > solution. I would love to do it via openssl library, but to do so,
I''d
>> > need
>> > to have a workable way to build CA''s and sign (and
revoke) client certs
>> > via
>> > openssl command - so far I cant reach that goal. I hope this makes
more
>> > sense now.
>> >
>> > Regards,
>> > S.
>> >
>> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank wrote:
>> >>
>> >> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote:
>> >> > after creating CA and client cert and applying them to
puppetmaster,
>> >> > it
>> >> > complains with:
>> >>
>> >> Wait, what? You create a new CA, even after agents have
already been
>> >> certified, then create new agent certificates?
>> >>
>> >> If your CA changes, you will have to terminate all the (now
deprecated)
>> >> agent certificates and sign new certificates for all agents.
>> >>
>> >> Basically, I would expect the outcome you are observing, and
you should
>> >> just follow the instructions given in your log excerpt. Note
that you
>> >> are *not* supposed to remove the CA from the master, only the
copy of
>> >> the agent''s certificate.
>> >>
>> >> HTH,
>> >> Felix
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Puppet Users" group.
>> > To unsubscribe from this group and stop receiving emails from it,
send
>> > an
>> > email to puppet-users...@googlegroups.com.
>> > To post to this group, send email to puppet...@googlegroups.com.
>> > Visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Dear Matt,

On Wednesday, February 20, 2013 10:39:51 PM UTC, Matt
wrote:
>
> I run an F5 load balancer with SSL termination at the F5 and I dont 
> need to put the CA cert anywhere except the F5. The actual CA signs 
> the certs. The CA cert is only really used to authenticate the client 
> cert. This gives the appearance to my puppet clients that I only have 
> one puppet master when in actuality I have around 4-5 per VIP. 
>
Unfortunately, I dont have F5 available and all I can have is software 
based load balancing, either in form of Haproxy (most probably) or Nginx 
(less probably).
 
>
> As for your last part I''m not really seeing how you think you
would
> need a puppetmaster per user. 
>
As one puppetmaster can use one CA at a time to sign/revoke certificates, 
if you''d have multiple users, you would need multiple puppetmasters, to
be
sure that two (or more) users can use different CA''s at the same time
to
sign/revoke their certs. Using openssl library and multiple instances of 
web app makes that possible, if using openssl to create CA''s and 
signing/revoking certs is possible in first place.
 
>
> On Wed, Feb 20, 2013 at 2:59 PM,  <spankt...@gmail.com
<javascript:>>
> wrote: 
> > Dear Matt, 
> > 
> > 
> > On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote: 
> >> 
> >> I think you''re trying to over complicate the situation
here.
> >> 
> >> Yes its a single point of failure but unfortunately that is not
going
> >> to change anytime between now and maybe 6 months. 
> > 
> > 
> > I am aware of that, and I am fine with that. 
> > 
> >> 
> >> 
> >> You do not need multiple CAs to use multiple puppet masters. The 
> >> client needs to have the setting ca_server set to the Puppet
Master
> >> that is the CA. You need to configure that Puppet master with ca =
> >> true. The puppet masters you create need to be configured with ca
=
> >> false. You can have 300 different puppet masters and each client
can
> >> connect to the different ones as needed. 
> > 
> > 
> > The thing is, the puppetmasters are exposed to puppet clients via 
> > loadbalancer, so they actually appear as one puppetmaster, therefore, 
> they 
> > all need to have the same CA installed. 
> > 
> >> 
> >> 
> >> If you need to limit which clients can connect to which puppet
masters
> >> then you should look at the auth.conf file. 
> >> 
> >> As for a web interface around certificate signing, when each
client
> >> connects into the CA it will submit its request and if autosign is
> >> turned off it should be setup to wait for certificate. The web 
> >> interface can be a wrapper around the puppet cert face so you can
get
> >> a list of certificates signed and whats waiting to be signed. You
can
> >> even set it up to revoke or clean out a certificate. You do not
need
> >> to call to the command line to do this either, you can interface
with
> >> the puppet api from rubygems. 
> > 
> > 
> > That, again, would require running puppetmaster per user, something I 
> > really, really want to avoid. 
> > 
> >> 
> >> 
> >> 
> >> On Tue, Feb 19, 2013 at 3:15 PM,  <spankt...@gmail.com>
wrote:
> >> > Dear Felix, 
> >> > 
> >> > I think you''re getting it wrong, let me clarify it a
bit. The goal of
> >> > this 
> >> > is to be able to write web interface for generating
puppetmasters
> CA''s 
> >> > and 
> >> > client certificates on demand. An example: install 3
puppetmasters
> with 
> >> > loadbalancer in front. Use web interface to generate CA and 
> certificates 
> >> > for 
> >> > chosen clients (lets say, 10 machines). Deploy such generated
CA''s on
> >> > puppetmasters, and relevant bits on puppet clients to
authorize them
> >> > against 
> >> > these puppetmasters. Whenever there''s need for
change, use that CA
> via 
> >> > web 
> >> > interface to add and delete client certificates, redeploy
them on
> >> > puppetmasters and so on. This, while doable via Subprocess
functions
> >> > (Python 
> >> > is the language of choice for me, but that doesnt really
matters) and
> >> > calls 
> >> > to relevant puppet system commands is extremely ugly and not
flexible
> >> > solution. I would love to do it via openssl library, but to
do so,
> I''d 
> >> > need 
> >> > to have a workable way to build CA''s and sign (and
revoke) client
> certs 
> >> > via 
> >> > openssl command - so far I cant reach that goal. I hope this
makes
> more 
> >> > sense now. 
> >> > 
> >> > Regards, 
> >> > S. 
> >> > 
> >> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank
wrote:
> >> >> 
> >> >> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote: 
> >> >> > after creating CA and client cert and applying them
to
> puppetmaster, 
> >> >> > it 
> >> >> > complains with: 
> >> >> 
> >> >> Wait, what? You create a new CA, even after agents have
already been
> >> >> certified, then create new agent certificates? 
> >> >> 
> >> >> If your CA changes, you will have to terminate all the
(now
> deprecated) 
> >> >> agent certificates and sign new certificates for all
agents.
> >> >> 
> >> >> Basically, I would expect the outcome you are observing,
and you
> should 
> >> >> just follow the instructions given in your log excerpt.
Note that
> you 
> >> >> are *not* supposed to remove the CA from the master, only
the copy
> of 
> >> >> the agent''s certificate. 
> >> >> 
> >> >> HTH, 
> >> >> Felix 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the
Google
> >> > Groups 
> >> > "Puppet Users" group. 
> >> > To unsubscribe from this group and stop receiving emails from
it,
> send 
> >> > an 
> >> > email to puppet-users...@googlegroups.com. 
> >> > To post to this group, send email to
puppet...@googlegroups.com.
> >> > Visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
> >> > For more options, visit
https://groups.google.com/groups/opt_out.
> >> > 
> >> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send
> an 
> > email to puppet-users...@googlegroups.com <javascript:>. 
> > To post to this group, send email to
puppet...@googlegroups.com<javascript:>.
>
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

I think you''re missing what I''m trying to convey. When you run
via
Apache or Nginx you are doing SSL termination at the apache and
forwarding the requests to a puppetmaster application if you use say
passenger. Its not so different than an F5. While I''m not giving you
exact details on how to do it I''m giving you enough information to
know its possible.

The value of ca_server defaults to "puppet", that means the
certificate of the server it connects to must have that name in the
cert and the DNS must match. When you start up the first puppet
master, the CA server and not with mod_passenger, it will
auto-generate the CA cert because the value of ca defaults to true if
its not otherwise specified in the puppet conf.

Essentially each puppet master that isnt the CA server is basically
just a puppet client meaning when it does its first run it will
generate a key, csr, and then try to connect to "puppet". You dont
actually need a cert for a puppet master if you do the ssl termination
at the load balancer. I provided a copy of my apache conf used for a
puppetmaster. As long as the puppetmasterd rack is installed it will
function as a puppetmaster with that config.

You need to generate a signed certificate from the CA for the load
balancer dns. Lets say your DNS for one pool is
puppetpool01.example.com, that is the cert name you need to generate
and install on the apache/nginx load balancer. You need to also
configure the load balancer to validate the ssl cert from the client
against the CA. Specific parameters need to be passed to puppet, which
is specified in the apache conf below. In each puppet master that is
load balanced in its conf file in the master section you need to put
these two lines

    ssl_client_header = SSL_CLIENT_S_DN
    ssl_client_verify_header = SSL_CLIENT_VERIFY

You want to go the mod_passenger route then you can do ssl termination
otherwise to do the tcp proxy is a real pain in the ass (been there,
done that, never again).

Below is an example of my apache conf where the communication is
unencrypted because of the ssl termination at the load balancer.

As long as the cert on the load balancer is signed by the CA and you
set it up to pass the correct headers if the SSL cert is validated
against the CA then you do not need multiple CA''s.

That way this setup you can revoke a certificate from one place
instead of trying to figure out which CA you need to revoke it from.
In each of my datacenters I have at the very minimum two F5 VIPs that
go to 4 different puppet masters each with one common CA. I have at
the current moment 6 datacenters, meaning I have 25 puppetmasters (24
servers, 1 CA).

Hopefully this clarifies the point I am conveying. I know my apache
configs, specifically for mod_passenger, might need tweaking but this
actually works really good. Also if you pick up one of the puppet
books, I forget which one exactly, they actually tell you how do the
proxying with apache in a similar fashion to what I explained.

#####
Apache Conf
#####

Listen 18140

PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 30
PassengerMaxRequests 10
PassengerStatThrottleRate 120
PassengerUseGlobalQueue on
RackAutoDetect On
RailsAutoDetect On
<VirtualHost *:18140>
        ServerName ppm001.example.com
        DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
        RackBaseURI /
        <Directory /usr/share/puppet/rack/puppetmasterd/public/>
                Options None
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
        SetEnvIf X-SSL-Subject "(.*)" SSL_CLIENT_S_DN=$1
        SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1
        SetEnvIf X-Forwarded-For "(.*)" REMOTE_ADDR=$1
        SetEnvIf X-Forwarded-Proto "https" HTTPS=1

        LogLevel error
        ErrorLog "|/usr/sbin/cronolog
/var/log/httpd/puppetmaster_error_log.%Y%m%d -l
/var/log/httpd/puppetmaster_error_log"
        CustomLog "|/usr/sbin/cronolog
/var/log/httpd/puppetmaster_access_log.%Y%m%d -l
/var/log/httpd/puppetmaster_access_log" combined
</VirtualHost>
#####

On Thu, Feb 21, 2013 at 9:36 AM,  <spankthespam@gmail.com>
wrote:
> Dear Matt,
>
>
> On Wednesday, February 20, 2013 10:39:51 PM UTC, Matt wrote:
>>
>> I run an F5 load balancer with SSL termination at the F5 and I dont
>> need to put the CA cert anywhere except the F5. The actual CA signs
>> the certs. The CA cert is only really used to authenticate the client
>> cert. This gives the appearance to my puppet clients that I only have
>> one puppet master when in actuality I have around 4-5 per VIP.
>
>
> Unfortunately, I dont have F5 available and all I can have is software
based
> load balancing, either in form of Haproxy (most probably) or Nginx (less
> probably).
>
>>
>>
>> As for your last part I''m not really seeing how you think you
would
>> need a puppetmaster per user.
>
>
> As one puppetmaster can use one CA at a time to sign/revoke certificates,
if
> you''d have multiple users, you would need multiple puppetmasters,
to be sure
> that two (or more) users can use different CA''s at the same time
to
> sign/revoke their certs. Using openssl library and multiple instances of
web
> app makes that possible, if using openssl to create CA''s and
> signing/revoking certs is possible in first place.
>
>>
>>
>> On Wed, Feb 20, 2013 at 2:59 PM,  <spankt...@gmail.com> wrote:
>> > Dear Matt,
>> >
>> >
>> > On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote:
>> >>
>> >> I think you''re trying to over complicate the
situation here.
>> >>
>> >> Yes its a single point of failure but unfortunately that is
not going
>> >> to change anytime between now and maybe 6 months.
>> >
>> >
>> > I am aware of that, and I am fine with that.
>> >
>> >>
>> >>
>> >> You do not need multiple CAs to use multiple puppet masters.
The
>> >> client needs to have the setting ca_server set to the Puppet
Master
>> >> that is the CA. You need to configure that Puppet master with
ca >> >> true. The puppet masters you create need to be configured
with ca >> >> false. You can have 300 different puppet masters and
each client can
>> >> connect to the different ones as needed.
>> >
>> >
>> > The thing is, the puppetmasters are exposed to puppet clients via
>> > loadbalancer, so they actually appear as one puppetmaster,
therefore,
>> > they
>> > all need to have the same CA installed.
>> >
>> >>
>> >>
>> >> If you need to limit which clients can connect to which puppet
masters
>> >> then you should look at the auth.conf file.
>> >>
>> >> As for a web interface around certificate signing, when each
client
>> >> connects into the CA it will submit its request and if
autosign is
>> >> turned off it should be setup to wait for certificate. The web
>> >> interface can be a wrapper around the puppet cert face so you
can get
>> >> a list of certificates signed and whats waiting to be signed.
You can
>> >> even set it up to revoke or clean out a certificate. You do
not need
>> >> to call to the command line to do this either, you can
interface with
>> >> the puppet api from rubygems.
>> >
>> >
>> > That, again, would require running puppetmaster per user,
something I
>> > really, really want to avoid.
>> >
>> >>
>> >>
>> >>
>> >> On Tue, Feb 19, 2013 at 3:15 PM,  <spankt...@gmail.com>
wrote:
>> >> > Dear Felix,
>> >> >
>> >> > I think you''re getting it wrong, let me clarify
it a bit. The goal of
>> >> > this
>> >> > is to be able to write web interface for generating
puppetmasters
>> >> > CA''s
>> >> > and
>> >> > client certificates on demand. An example: install 3
puppetmasters
>> >> > with
>> >> > loadbalancer in front. Use web interface to generate CA
and
>> >> > certificates
>> >> > for
>> >> > chosen clients (lets say, 10 machines). Deploy such
generated CA''s on
>> >> > puppetmasters, and relevant bits on puppet clients to
authorize them
>> >> > against
>> >> > these puppetmasters. Whenever there''s need for
change, use that CA
>> >> > via
>> >> > web
>> >> > interface to add and delete client certificates, redeploy
them on
>> >> > puppetmasters and so on. This, while doable via
Subprocess functions
>> >> > (Python
>> >> > is the language of choice for me, but that doesnt really
matters) and
>> >> > calls
>> >> > to relevant puppet system commands is extremely ugly and
not flexible
>> >> > solution. I would love to do it via openssl library, but
to do so,
>> >> > I''d
>> >> > need
>> >> > to have a workable way to build CA''s and sign
(and revoke) client
>> >> > certs
>> >> > via
>> >> > openssl command - so far I cant reach that goal. I hope
this makes
>> >> > more
>> >> > sense now.
>> >> >
>> >> > Regards,
>> >> > S.
>> >> >
>> >> > On Tuesday, February 19, 2013 4:04:32 PM UTC, Felix.Frank
wrote:
>> >> >>
>> >> >> On 02/16/2013 12:20 PM, spankt...@gmail.com wrote:
>> >> >> > after creating CA and client cert and applying
them to
>> >> >> > puppetmaster,
>> >> >> > it
>> >> >> > complains with:
>> >> >>
>> >> >> Wait, what? You create a new CA, even after agents
have already been
>> >> >> certified, then create new agent certificates?
>> >> >>
>> >> >> If your CA changes, you will have to terminate all
the (now
>> >> >> deprecated)
>> >> >> agent certificates and sign new certificates for all
agents.
>> >> >>
>> >> >> Basically, I would expect the outcome you are
observing, and you
>> >> >> should
>> >> >> just follow the instructions given in your log
excerpt. Note that
>> >> >> you
>> >> >> are *not* supposed to remove the CA from the master,
only the copy
>> >> >> of
>> >> >> the agent''s certificate.
>> >> >>
>> >> >> HTH,
>> >> >> Felix
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to
the Google
>> >> > Groups
>> >> > "Puppet Users" group.
>> >> > To unsubscribe from this group and stop receiving emails
from it,
>> >> > send
>> >> > an
>> >> > email to puppet-users...@googlegroups.com.
>> >> > To post to this group, send email to
puppet...@googlegroups.com.
>> >> > Visit this group at
>> >> > http://groups.google.com/group/puppet-users?hl=en.
>> >> > For more options, visit
https://groups.google.com/groups/opt_out.
>> >> >
>> >> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Puppet Users" group.
>> > To unsubscribe from this group and stop receiving emails from it,
send
>> > an
>> > email to puppet-users...@googlegroups.com.
>> > To post to this group, send email to puppet...@googlegroups.com.
>> > Visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Oh and to add to my message. The benefit of this is there is no
tomfoolery with multiple CAs and the confusion that will cause. If the
concern is about letting one puppet client connect to two different
pools then you can limit who can retrieve their catalog either through
the auth.conf or directives via apache/nginx directives.

The only time a new CA would be required is if you cant isolate via
auth.conf or apache/ngnix and that would depend on the topology of
your network. If you are concerned with a rogue server then you have
autosign off then this is less of a issue because you actually have to
authorize, by signing the certificate, the client to connect to any
puppet master/pool signed by the CA.



On Fri, Feb 22, 2013 at 10:31 AM, Matthew Black <mjblack@gmail.com>
wrote:
> I think you''re missing what I''m trying to convey. When
you run via
> Apache or Nginx you are doing SSL termination at the apache and
> forwarding the requests to a puppetmaster application if you use say
> passenger. Its not so different than an F5. While I''m not giving
you
> exact details on how to do it I''m giving you enough information to
> know its possible.
>
> The value of ca_server defaults to "puppet", that means the
> certificate of the server it connects to must have that name in the
> cert and the DNS must match. When you start up the first puppet
> master, the CA server and not with mod_passenger, it will
> auto-generate the CA cert because the value of ca defaults to true if
> its not otherwise specified in the puppet conf.
>
> Essentially each puppet master that isnt the CA server is basically
> just a puppet client meaning when it does its first run it will
> generate a key, csr, and then try to connect to "puppet". You
dont
> actually need a cert for a puppet master if you do the ssl termination
> at the load balancer. I provided a copy of my apache conf used for a
> puppetmaster. As long as the puppetmasterd rack is installed it will
> function as a puppetmaster with that config.
>
> You need to generate a signed certificate from the CA for the load
> balancer dns. Lets say your DNS for one pool is
> puppetpool01.example.com, that is the cert name you need to generate
> and install on the apache/nginx load balancer. You need to also
> configure the load balancer to validate the ssl cert from the client
> against the CA. Specific parameters need to be passed to puppet, which
> is specified in the apache conf below. In each puppet master that is
> load balanced in its conf file in the master section you need to put
> these two lines
>
>     ssl_client_header = SSL_CLIENT_S_DN
>     ssl_client_verify_header = SSL_CLIENT_VERIFY
>
> You want to go the mod_passenger route then you can do ssl termination
> otherwise to do the tcp proxy is a real pain in the ass (been there,
> done that, never again).
>
> Below is an example of my apache conf where the communication is
> unencrypted because of the ssl termination at the load balancer.
>
> As long as the cert on the load balancer is signed by the CA and you
> set it up to pass the correct headers if the SSL cert is validated
> against the CA then you do not need multiple CA''s.
>
> That way this setup you can revoke a certificate from one place
> instead of trying to figure out which CA you need to revoke it from.
> In each of my datacenters I have at the very minimum two F5 VIPs that
> go to 4 different puppet masters each with one common CA. I have at
> the current moment 6 datacenters, meaning I have 25 puppetmasters (24
> servers, 1 CA).
>
> Hopefully this clarifies the point I am conveying. I know my apache
> configs, specifically for mod_passenger, might need tweaking but this
> actually works really good. Also if you pick up one of the puppet
> books, I forget which one exactly, they actually tell you how do the
> proxying with apache in a similar fashion to what I explained.
>
> #####
> Apache Conf
> #####
>
> Listen 18140
>
> PassengerHighPerformance on
> PassengerMaxPoolSize 12
> PassengerPoolIdleTime 30
> PassengerMaxRequests 10
> PassengerStatThrottleRate 120
> PassengerUseGlobalQueue on
> RackAutoDetect On
> RailsAutoDetect On
> <VirtualHost *:18140>
>         ServerName ppm001.example.com
>         DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
>         RackBaseURI /
>         <Directory /usr/share/puppet/rack/puppetmasterd/public/>
>                 Options None
>                 AllowOverride None
>                 Order allow,deny
>                 allow from all
>         </Directory>
>         SetEnvIf X-SSL-Subject "(.*)" SSL_CLIENT_S_DN=$1
>         SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1
>         SetEnvIf X-Forwarded-For "(.*)" REMOTE_ADDR=$1
>         SetEnvIf X-Forwarded-Proto "https" HTTPS=1
>
>         LogLevel error
>         ErrorLog "|/usr/sbin/cronolog
> /var/log/httpd/puppetmaster_error_log.%Y%m%d -l
> /var/log/httpd/puppetmaster_error_log"
>         CustomLog "|/usr/sbin/cronolog
> /var/log/httpd/puppetmaster_access_log.%Y%m%d -l
> /var/log/httpd/puppetmaster_access_log" combined
> </VirtualHost>
> #####
>
> On Thu, Feb 21, 2013 at 9:36 AM,  <spankthespam@gmail.com> wrote:
>> Dear Matt,
>>
>>
>> On Wednesday, February 20, 2013 10:39:51 PM UTC, Matt wrote:
>>>
>>> I run an F5 load balancer with SSL termination at the F5 and I dont
>>> need to put the CA cert anywhere except the F5. The actual CA signs
>>> the certs. The CA cert is only really used to authenticate the
client
>>> cert. This gives the appearance to my puppet clients that I only
have
>>> one puppet master when in actuality I have around 4-5 per VIP.
>>
>>
>> Unfortunately, I dont have F5 available and all I can have is software
based
>> load balancing, either in form of Haproxy (most probably) or Nginx
(less
>> probably).
>>
>>>
>>>
>>> As for your last part I''m not really seeing how you think
you would
>>> need a puppetmaster per user.
>>
>>
>> As one puppetmaster can use one CA at a time to sign/revoke
certificates, if
>> you''d have multiple users, you would need multiple
puppetmasters, to be sure
>> that two (or more) users can use different CA''s at the same
time to
>> sign/revoke their certs. Using openssl library and multiple instances
of web
>> app makes that possible, if using openssl to create CA''s and
>> signing/revoking certs is possible in first place.
>>
>>>
>>>
>>> On Wed, Feb 20, 2013 at 2:59 PM,  <spankt...@gmail.com>
wrote:
>>> > Dear Matt,
>>> >
>>> >
>>> > On Wednesday, February 20, 2013 5:41:11 PM UTC, Matt wrote:
>>> >>
>>> >> I think you''re trying to over complicate the
situation here.
>>> >>
>>> >> Yes its a single point of failure but unfortunately that
is not going
>>> >> to change anytime between now and maybe 6 months.
>>> >
>>> >
>>> > I am aware of that, and I am fine with that.
>>> >
>>> >>
>>> >>
>>> >> You do not need multiple CAs to use multiple puppet
masters. The
>>> >> client needs to have the setting ca_server set to the
Puppet Master
>>> >> that is the CA. You need to configure that Puppet master
with ca >>> >> true. The puppet masters you create need to be
configured with ca >>> >> false. You can have 300 different
puppet masters and each client can
>>> >> connect to the different ones as needed.
>>> >
>>> >
>>> > The thing is, the puppetmasters are exposed to puppet clients
via
>>> > loadbalancer, so they actually appear as one puppetmaster,
therefore,
>>> > they
>>> > all need to have the same CA installed.
>>> >
>>> >>
>>> >>
>>> >> If you need to limit which clients can connect to which
puppet masters
>>> >> then you should look at the auth.conf file.
>>> >>
>>> >> As for a web interface around certificate signing, when
each client
>>> >> connects into the CA it will submit its request and if
autosign is
>>> >> turned off it should be setup to wait for certificate. The
web
>>> >> interface can be a wrapper around the puppet cert face so
you can get
>>> >> a list of certificates signed and whats waiting to be
signed. You can
>>> >> even set it up to revoke or clean out a certificate. You
do not need
>>> >> to call to the command line to do this either, you can
interface with
>>> >> the puppet api from rubygems.
>>> >
>>> >
>>> > That, again, would require running puppetmaster per user,
something I
>>> > really, really want to avoid.
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Feb 19, 2013 at 3:15 PM, 
<spankt...@gmail.com> wrote:
>>> >> > Dear Felix,
>>> >> >
>>> >> > I think you''re getting it wrong, let me
clarify it a bit. The goal of
>>> >> > this
>>> >> > is to be able to write web interface for generating
puppetmasters
>>> >> > CA''s
>>> >> > and
>>> >> > client certificates on demand. An example: install 3
puppetmasters
>>> >> > with
>>> >> > loadbalancer in front. Use web interface to generate
CA and
>>> >> > certificates
>>> >> > for
>>> >> > chosen clients (lets say, 10 machines). Deploy such
generated CA''s on
>>> >> > puppetmasters, and relevant bits on puppet clients to
authorize them
>>> >> > against
>>> >> > these puppetmasters. Whenever there''s need
for change, use that CA
>>> >> > via
>>> >> > web
>>> >> > interface to add and delete client certificates,
redeploy them on
>>> >> > puppetmasters and so on. This, while doable via
Subprocess functions
>>> >> > (Python
>>> >> > is the language of choice for me, but that doesnt
really matters) and
>>> >> > calls
>>> >> > to relevant puppet system commands is extremely ugly
and not flexible
>>> >> > solution. I would love to do it via openssl library,
but to do so,
>>> >> > I''d
>>> >> > need
>>> >> > to have a workable way to build CA''s and
sign (and revoke) client
>>> >> > certs
>>> >> > via
>>> >> > openssl command - so far I cant reach that goal. I
hope this makes
>>> >> > more
>>> >> > sense now.
>>> >> >
>>> >> > Regards,
>>> >> > S.
>>> >> >
>>> >> > On Tuesday, February 19, 2013 4:04:32 PM UTC,
Felix.Frank wrote:
>>> >> >>
>>> >> >> On 02/16/2013 12:20 PM, spankt...@gmail.com
wrote:
>>> >> >> > after creating CA and client cert and
applying them to
>>> >> >> > puppetmaster,
>>> >> >> > it
>>> >> >> > complains with:
>>> >> >>
>>> >> >> Wait, what? You create a new CA, even after
agents have already been
>>> >> >> certified, then create new agent certificates?
>>> >> >>
>>> >> >> If your CA changes, you will have to terminate
all the (now
>>> >> >> deprecated)
>>> >> >> agent certificates and sign new certificates for
all agents.
>>> >> >>
>>> >> >> Basically, I would expect the outcome you are
observing, and you
>>> >> >> should
>>> >> >> just follow the instructions given in your log
excerpt. Note that
>>> >> >> you
>>> >> >> are *not* supposed to remove the CA from the
master, only the copy
>>> >> >> of
>>> >> >> the agent''s certificate.
>>> >> >>
>>> >> >> HTH,
>>> >> >> Felix
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed
to the Google
>>> >> > Groups
>>> >> > "Puppet Users" group.
>>> >> > To unsubscribe from this group and stop receiving
emails from it,
>>> >> > send
>>> >> > an
>>> >> > email to puppet-users...@googlegroups.com.
>>> >> > To post to this group, send email to
puppet...@googlegroups.com.
>>> >> > Visit this group at
>>> >> > http://groups.google.com/group/puppet-users?hl=en.
>>> >> > For more options, visit
https://groups.google.com/groups/opt_out.
>>> >> >
>>> >> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the
Google
>>> > Groups
>>> > "Puppet Users" group.
>>> > To unsubscribe from this group and stop receiving emails from
it, send
>>> > an
>>> > email to puppet-users...@googlegroups.com.
>>> > To post to this group, send email to
puppet...@googlegroups.com.
>>> > Visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>>> > For more options, visit
https://groups.google.com/groups/opt_out.
>>> >
>>> >
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to puppet-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.