Puppet

I have had a similar problem using nginx, new nodes aren’t able to get a CSR properly and in order to get them setup, I will kill nginx and the mongrels and instead run puppetmaster —no-daemonize -v and then run the node to get the certificate setup, puppetca it and then once everything is set, re-run the mongrels and nginx. I’d like to switch back to apache/mongrel to see if this changes anything.

Micah’s solution does work for me. It’s ugly but keeps me going for now.

For nginx you need to run a seperate instance on another port (e.g. 8141) for doing the CSR stuff, and —ca_port 8141 for new clients.

The tlsv1 decrypt thing I’ve seen w/ apache before, and that was due to the CRL

I cannot seem to reply or edit at the moment (probably javascript issues), so here’s another comment:

Micah’s solution works and lets me sign new certificates; however, on every run of puppetd, it (‘puppetd’ in the logs) complains about the tlsvs1 verification error and no actual configuration will happen since presumably it cannot establish the authenticity of the server.

For nginx you need to run a seperate instance on another port (e.g. 8141) for doing the CSR stuff, and —ca_port 8141 for new clients.

This is correct, once I tweaked my nginx config to be like the one on the wiki, with a 8141 port running, then this works.

This problem is also present on 0.24.5 (Debian Lenny) — I’ve recently deployed Apache/Mongrel in front of my puppetmasterd, and now the puppetd on the puppetmasterd host can’t sync if CRL is enabled:

Sep  6 16:45:07 host puppetd[23706]: Could not retrieve catalog: Certificates were not trusted: SSL_connect returned=1 errno=0 state=SSLv3 read finished A: tlsv1 alert decrypt error

All other (two, ATM) puppetd’s can happily connect to the puppetmasterd using Apache as their proxy. I used the second Apache configuration at http://reductivelabs.com/trac/puppet/wiki/UsingMongrel for this.

In my case, if I comment SSLCARevocationFile it starts working.

This is a snippet of my Apache configuration for this:

SSLEngine on
SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
SSLCertificateFile /var/lib/puppet/ssl/certs/host.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/host.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth  1
SSLOptions +StdEnvVars
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
<Location />
   Order allow,deny
   Allow from all
</Location>
ProxyPass / http://127.0.0.1:18140/
ProxyPassReverse / http://127.0.0.1:18140/
ProxyPreserveHost on

Thanks for your time!

I was just about to close this bug not having seen this problem in months when it re-appeared out of the blue (I did not make any changes whatsoever). Still, commenting out SSLCARevocationFile in the apache.conf makes it all work. The CRL still has no revoked certificates, according to

openssl crl -text -noout -in /var/lib/puppet/ssl/ca/ca_crl.pem