client connection errors: SSL, SNI and DNS_ALT_NAMES Oh My

[Jonathan Proulx]

Hi All,

I've run into a bit of a tangle.

I currently have two puppet masters which are "load balanced" with round robin DNS (one is also the CA).  I'm using dns_alt_names to let them each answer to puppet.my.domain.com

For the past year this has been fine.

About a week ago I tried  to add a third & while all my Linux clients are happy with the new arrangement, my smaller number of FreeBSD9 systems fail with:

puppet-agent[73345]: Failed to apply catalog: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: (null)

when hitting the newly deployed server.  If I give the specific host name as the --server argument (rather than the alternative name that get the round robin dns) puppet agent connects runs properly.

I've tracked this down to the FreeBSD client using SNI where as the Linux clients do not and the older servers don't support SNI so it is ignored.

All server are using apache mod_ssl and passenger, but I'm not sure how to proceed.

I could generate a "puppet.my.domain.com" certificate, distribute it to all the servers and set up name based virtual hosts that SNI is designed to facilitate, but then I can't selectively revoke the certs if there's a security issue with one server, so I'd rather keep my per host certificates with dns_alt_names.

This is probably more of an apache question now, but does anyone here know how to get Apache to accept an SNI for a name that is a dns_alt_name of a cert rather than the CN?  Or more puppetly if there's a config option to not send an SNI from the client?  Though that seems the wrong way to fix the problem.

Thanks,

-Jon

[Nabil Servais]

Hello,

I tried different configuration with SNI and authentication (classic certificates or puppet), I could say it's impossible. Maybe I miss something but I don't think so. 

You have to use an another dns name or use a different port.

good luck.

--
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...@googlegroups.com.
To post to this group, send email to puppet...@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.
 
 

[Jonathan Proulx]

So turns out to be a very simple solution, all I needed was to set a "ServerAlias" apache directive for the alternate dns name.  Since this is the only service apache on these systems serves I'd been sloppy and didn't specify any ServerName or ServerAlias, relying on everything being the default case which was OK before clients used SNI but now you need to be explicit.

-Jon

[Josh Cooper]

Ruby 1.9.0 added SNI support to Net::HTTP in https://github.com/ruby/ruby/commit/afe7aac47b11693090f552df05f894d2ced8ada3. If ruby was compiled with a version of openssl that supports SNI, you'll get this new behavior (the ssl client always sending the SNI TLS extension).

Josh

--

Josh Cooper

Developer, Puppet Labs

Join us at PuppetConf 2013, August 22-23 in San Francisco - http://bit.ly/pupconf13
Register now and take advantage of the Early Bird discount - save 25%!