Puppet users - Jan 2011 - Puppet master cannot connect to self

Hi, I have a the annoying problem that the puppet master cannot connect
 to itself. It fails with:

puppet# puppetd --test
err: Could not retrieve catalog from remote server: SSL_connect returned=1
errno=0 state=SSLv3 read finished A: tlsv1 alert decrypt error


History:

I have had this problem on our old puppet server: puppet.domain.com. It was
annoying but not critical.

Recently I built a new puppet server (on new hardware) with the new name
puppetmaster.domain.com and moved all nodes to that new master
successfully by rsyncing $ssldir, and server=puppetmaster.domain.com and
certdnsnames=puppetmaster.domain.com:puppetmaster:puppet.domain.com:puppet
in puppet.conf. Both puppet.domain.com and puppetmaster.domain.com resolve
to the IP of the new server. See <20110118184147.GF730@wiet.xs4all.net> to
this list for details.

Suddenly I discovered that the puppet agent on this new server could
actually connect to itself. I was very happy.

But then came the time that the old server was dismanteled and I wanted
to give the new server the old hostname: puppet.domain.com: I revoked and
cleaned the old cert of the old host, modified puppet.conf to contain
server=puppet.domain.com, modified Apache to read the new (soon to be
generated) SSLCertificateFile, changed its hostname and rebooted.

After reboot all nodes could connect successfully *except* the puppet
server itself: the old error message was back.

After some digging, I found in $ssldir the following files that were
created around the time that the old puppet server was created:
  certs/ca.pem
  ca/private/ca.pass
  ca/ca_crt.pem
  ca/ca_pub.pem
  ca/ca_key.pem

certs/ca.pem and ca/ca_crt.pem (which are identical files) both contain:
  Issuer: CN=puppet.domain.com
  Validity
      Not Before: Mar 25 15:51:31 2008 GMT
      Not After : Mar 24 15:51:31 2013 GMT
  Subject: CN=puppet.domain.com

I imagine I could solve this problem by completely throwing away $ssldir,
letting the puppetmaster recreate it from scratch, but that would mean that
I have to login to each node, remove $ssldir there as well, and sign its
new CSR.

Is there a way to solve this problem without doing that?

Regards,
Robert Scheer

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

Hi Robert,

Yes, you shouldn''t need to delete $ssldir on the Master. I''ll
reply to
you fully tomorrow (or someone on American time can this evening). The
error itself is strange (TLS handshake?) but describing what you''ve
done I''d think you''d have a certificate / hostname mismatch
problem.

Have a look at Dan Bode''s blog post about sharing a CA, it has the
commands for generating puppet certs with additional Cert DNS names:
http://bodepd.com/wordpress/?p=7

Down the bottom of Masterzen''s blog post are some helpful openssl
commands for checking certificates:
http://www.masterzen.fr/2010/11/14/puppet-ssl-explained/

You can also generate a certificate on your Puppet Master with the
name ''puppet'' to be used by Apache, then use one for your
Puppet
Master as a Puppet client to use (a master cert and a client cert).

But don''t delete the CA yet ;)

-Luke

On Jan 24, 3:08 pm, Robert Scheer <r...@xs4all.net>
wrote:
> certs/ca.pem and ca/ca_crt.pem (which are identical files) both contain:
>   Issuer: CN=puppet.domain.com
>   Validity
>       Not Before: Mar 25 15:51:31 2008 GMT
>       Not After : Mar 24 15:51:31 2013 GMT
>   Subject: CN=puppet.domain.com
>
> I imagine I could solve this problem by completely throwing away $ssldir,
> letting the puppetmaster recreate it from scratch, but that would mean that
> I have to login to each node, remove $ssldir there as well, and sign its
> new CSR.
>
> Is there a way to solve this problem without doing that?
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Jan 24, 2011 at 09:21 -0800, luke.bigum wrote:
> Down the bottom of Masterzen''s blog post are some helpful openssl
> commands for checking certificates:
> http://www.masterzen.fr/2010/11/14/puppet-ssl-explained/
Thanks for the info, I figured it out!

The key to the solution was the part where Masterzen explains about the
server certificate. There he writes: "If your master is also a client of
itself (ie it runs a puppet agent), I recommend using this certificate as
the client certificate."

So what I did, was:
# cp ca/ca_crt.pem ./ca/signed/puppet.xs4all.net.pem
# cp ca/ca_crt.pem ./certs/puppet.xs4all.net.pem
# cp ca/ca_key.pem ./private_keys/puppet.xs4all.net.pem
# cp ca/ca_pub.pem ./public_keys/puppet.xs4all.net.pem

Then this happened:
# puppet agent --test --noop
Enter PEM pass phrase:

And when I entered the string from ca/private/ca.pass, it worked!

So the only thing left to do, was remove the pass phrase from the client
certificate:

# mv ./private_keys/puppet.xs4all.net.pem /tmp/foo
# openssl rsa -in /tmp/foo -out ./private_keys/puppet.xs4all.net.pem
Enter pass phrase for /tmp/foo:
writing RSA key

And then it worked!

# puppet agent --test --noop
info: Caching catalog for puppet.xs4all.net
info: Applying configuration version ''1295962955''
...

Thanks again for your help.
Robert Scheer

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