Re: [Puppet Users] Puppet Scalability - Centralised Puppet SSL Cert Issues
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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet Scalability - Centralised Puppet SSL Cert Issues
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.compuppet-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.
Re: [Puppet Users] Puppet Scalability - Centralised Puppet SSL Cert Issues
Thanks Ohad I have updated the Wiki entry with a warning (where's the blink tag?) and references to the bugs on certificate chaining I'm not 100% comfortable with a single CA, so would it be possible to do the following: ca_server = puppet-ca.example.com rsync the ssl dir every 5 minutes to puppet-ca2.example.com If puppet-ca dies, I would swing the CNAME over to puppet-ca2.example.com Thanks John On 1 September 2010 16:37, Ohad Levy ohadl...@gmail.com wrote: 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.compuppet-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.compuppet-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- John Warburton Ph: 0417 299 600 Email: jwarbur...@gmail.com -- 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.
[Puppet Users] Puppet Scalability - Centralised Puppet SSL Cert Issues
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? Thanks John I have Solaris 10 Update 8 0.25.5 puppeteer, client and server, and Apache 2.2.15 with rack and the following gems: fastthread (1.0.7) passenger (2.2.14) rack (1.1.0) rake (0.8.7) I start with a clean config on my puppeteer: cornadm010# nslookup puppet.example.com Server: 1.2.3.4 Address:4.5.6.7#53 puppet.example.com canonical name = cornadm010.example.com. Name: cornadm010.example.com cornadm010# /opt/local/sbin/puppetmasterd --server puppet.example.com--certname puppet.example.com --certdnsname `uname -n`.example.com:puppet.example.com--genconfig --vardir=/local/puppet/var --confdir=/local/puppet/etc --pluginsync --ssl_client_header=SSL_CLIENT_S_DN --ssl_client_verify_header=SSL_CLIENT_VERIFY --reports store --autosign /local/puppet/etc/autosign.conf --node_terminus exec --external_nodes /local/puppet/bin/node_classifier.pl | sed -e 's/genconfig = true/genconfig = false/' /local/puppet/etc/puppetmasterd.conf cornadm010# \rm -rf /local/puppet/etc/ssl r...@cornadm010# /opt/local/sbin/puppetmasterd --no-daemonize --verbose --config /local/puppet/etc/puppetmasterd.conf info: Creating a new SSL key for ca info: Creating a new SSL certificate request for ca notice: Signed certificate request for ca notice: Rebuilding inventory file info: Creating a new certificate revocation list info: Creating a new SSL key for puppet.example.com info: Creating a new SSL certificate request for puppet.example.com notice: puppet.example.com has a waiting certificate request info: authstore: defaulting to no access for puppet.example.com notice: Signed certificate request for puppet.example.com notice: Removing file Puppet::SSL::CertificateRequest puppet.example.com at '/local/puppet/etc/ssl/ca/requests/puppet.example.com.pem' notice: Removing file Puppet::SSL::CertificateRequest puppet.example.com at '/local/puppet/etc/ssl/certificate_requests/puppet.example.com.pem' notice: Starting Puppet server version 0.25.5 r...@engnsvr002# /opt/local/sbin/puppetmasterd --server `uname -n`. example.com --certname `uname -n`.example.com --certdnsname `uname -n`. example.com --genconfig --vardir=/local/puppet/var --confdir=/local/puppet/etc --pluginsync --ssl_client_header=SSL_CLIENT_S_DN --ssl_client_verify_header=SSL_CLIENT_VERIFY --reports store --autosign /local/puppet/etc/autosign.conf --node_terminus exec --external_nodes /local/puppet/bin/node_classifier.pl | sed -e 's/genconfig = true/genconfig = false/' /local/puppet/etc/puppetmasterd.conf r...@engnsvr002# \rm -rf /local/puppet/etc/ssl r...@engnsvr002# /opt/local/sbin/puppetmasterd --no-daemonize --verbose --config /local/puppet/etc/puppetmasterd.conf info: Creating a new SSL key for ca info: Creating a new SSL certificate request for ca notice: Signed certificate request for ca notice: Rebuilding inventory file info: Creating a new certificate revocation list info: Creating a new SSL key for engnsvr002.example.com info: Creating a new SSL certificate request for engnsvr002.example.com notice: engnsvr002.example.com has a waiting certificate request notice: Signed certificate request for engnsvr002.example.com notice: Removing file Puppet::SSL::CertificateRequest engnsvr002.example.comat '/local/puppet/etc/ssl/ca/requests/engnsvr002.example.com.pem' notice: Removing file Puppet::SSL::CertificateRequest engnsvr002.example.comat '/local/puppet/etc/ssl/certificate_requests/engnsvr002.example.com.pem' notice: Starting Puppet server version 0.25.5 r...@engnsvr002# egrep example.com /tmp/openssl.cnf commonName = engnsvr002.example.com nsCaRevocationUrl =
