Puppet users - May 2013 - freebsd clients failing to connect to new master with ssl errors

Hi All,

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.

Today I''m trying to add a third & while all my Linux clients seem
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.  To make matters more frustrating
openssl s_client -connect puppet.my.domain.com:8140 seems to work from the
failing clients to the new server and 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.

All clients and servers are running Puppet 3.1.1

Any pointers on where to look or guess at what I got wrong?

-Jon

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

This smells like a problem related to incorrect system clock when the cert
was generated for the new master.?.

-- 
---
Nathan Valentine - nathan@puppetlabs.com
Puppet Labs Professional Services
GV: 415.504.2173
Skype: nrvale0

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%!

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

But I''m game, short of regenerating the new master''s
certificate & trying
the clients again anything to look at to test that theory?

Time is frequently a good place to look in crypto errors, but we rely on
Kerberos for just about everything which is also very time sensitive so
we''re pretty scrupulous about time to the point of running our own
stratum
1 CDMA time server.  Now that''s not to say things never go wrong there,
but
when they do it''s usually pretty obvious.  I hadn''t had my
monitoring setup
on the new master when I generated the cert so I can''t be 100% sure I
can
see that the CA''s worst offset in the past week was 1.68ms, while
testing
yesterday afternoon the new master never got more than 1ms out.

The real kicker is that the FreeBSD clients could connect when calling the
server by it''s primary DNS name but not by the shared service name,
seems
if time were at issue that would not work either.

One thing that does jump out is the FreeBSD clients are using Ruby1.9 while
the Linux Clients and servers are on 1.8

Also the new master is using openssl 1.0.1 the older masters are using
0.9.8o and the FreeBSD Clients 0.9.8.y, though Linux clients use 0.9.8o and
1.0.1 so don''t *think* that''s it.

Thanks,
-Jon




On Tue, May 7, 2013 at 5:45 PM, Nathan Valentine
<nathan@puppetlabs.com>wrote:
> This smells like a problem related to incorrect system clock when the cert
> was generated for the new master.?.
>
> --
> ---
> Nathan Valentine - nathan@puppetlabs.com
> Puppet Labs Professional Services
> GV: 415.504.2173
> Skype: nrvale0
>
> 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%!
>
> --
> 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+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@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.
>
>
>
-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@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.

On Wed, May 8, 2013 at 8:55 AM, Jonathan Proulx <jon@jonproulx.com> wrote:
> I''m game, short of regenerating the new master''s
certificate & trying the
> clients again anything to look at to test that theory?
>
>
Well new certs are easy enough so went a head and generated new ones after
checking CA, new server and test client time against ntp server (everyone
was good), but no dice same errors and non errors.

for my next straw to grasp going to setup a linux client with Ruby1.9 and
see if that fails (verified openssl 1.0.1 and 0.9.8o linux clients work)

-jon

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