There is an open bug with 0.25.x (and 2.6) which breaks certificate chaining. this works well for the 0.24.x series, and I hope that will work again sometime in the near future with 2.6.x series.
I would recommend you at the moment to use one machine as the CA, if you can accept the fact that its a single point of failure for creating new certificates. Ohad On Wed, Sep 1, 2010 at 9:14 AM, Patrick <kc7...@gmail.com> wrote: > > On Aug 31, 2010, at 10:47 PM, John Warburton wrote: > > Hi All > > I am trying to use the section on Centralised Puppet Infrastructure on the > Scaling Puppet page - > http://projects.puppetlabs.com/projects/1/wiki/Puppet_Scalability > > No matter what I do, I always end up with the client contacting a puppet > server and rejecting the configuration with a dreaded "certificate verify > failed": > > err: /File[/var/puppet/confdir/var/lib]: Failed to retrieve current state > of resource: SSL_connect returned=1 errno=0 state=SSLv3 read server > certificate B: certificate verify failed Could not retrieve file metadata > for puppet://engnsvr002.example.com/plugins: SSL_connect returned=1 > errno=0 state=SSLv3 read server certificate B: certificate verify failed > > I have started from completely fresh servers, and repeated this behavior a > number of times, with clean puppet configs - you can see a very detailed > working below. > > I am stumped as to what to do next, but suspect a number of things: > - the example given was for Mongrel - is Passenger different? > - there are a number SSL cert chaining tickets in the issues list > > My goal is to have any puppet client be able to talk to any puppet server, > so that if one.s designated puppet server died, we could repoint its CNAME > to another puppet server in another datacentre and the client would continue > working as if nothing happened. Does anyone have a working configuration > that fits this scenario? > > > I've done it 2 ways. > 1) Just copy the ca folder to the other servers. (Warning, breaks > certificate revocation because of duplicate serial numbers) > 2) Use one server as the ca for everything, but have local servers for > everything else. (Not as much reliability, but close. You can't sign when > the ca goes down, but everything else works.) > > I have tried using that method, but I've had horrible luck and didn't > manage to make it work. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
