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+unsubscr...@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.
