[Puppet-users] SSL subjectAltName (was RE: Warning for Fedora Core users)

[Derek.Whayman at barclayscapital.com]

To recap, the newest versions of Ruby (see below) check the hostname
strictly when connecting to a server.  If your $server is not exactly
what's on the CN of the server cert, the connection is rejected.  Since
we tend to use CNAMEs and/or not use the FQDN when connecting, this is
going to sting badly when the newer Ruby filters down to our RHEL
packages.

I've confirmed that David L's subjectAltName idea works for sure.  In
sslcertificates.rb I add 

(when :server:)
ex << ef.create_extension("subjectAltName", subject_alt_name.join(","))

Example:
subject_alt_name = %w{DNS:puppet DNS:puppet.intranet.barcapint.com
DNS:engpsr0142}

You can then see in the server cert:
# openssl x509 -noout -text -in
/var/lib/puppet/ssl/certs/engpsr0142.intranetdev.barcapdev.com.pem
...
            X509v3 Subject Alternative Name: 
                DNS:puppet, DNS:puppet.intranet.barcapint.com,
DNS:engpsr0142
...

And Lo, my Fedora 7 client verifies the certificate happily.

The unfortunate thing is that when you regenerate the cert you need to
have all your clients re-sign :-(

***************************************************
Question is, how should this be implemented?  Should there be a
configuration parameter that is a colon-separated list of DNS names for
your Puppetmaster?
***************************************************

And are there any SSL gurus out there how could suggest an architecture
that makes it easy for me to add more Puppetmasters as we keep on adding
new locations?  I suppose I should knuckle down to reading
http://reductivelabs.com/trac/puppet/wiki/MultipleCertificateAuthorities
again.

Regards,
Derek


-----Original Message-----
From: puppet-users-bounces at madstop.com
[mailto:puppet-users-bounces at madstop.com] On Behalf Of David Lutterkort
Sent: 11 October 2007 00:21
To: alext at picorp.com; Puppet User Discussion
Subject: Re: [Puppet-users] Warning for Fedora Core users

On Wed, 2007-10-10 at 15:07 +0530, Alexander Taler wrote:
> Fedora Core 7 has just updated their Ruby package (was 1.8.6.36-3.fc7,

> is now 1.8.6.110-3.fc7), and the upgrade broke my Puppet installation,

> and there was a similar report from someone else.
> 
> Communications between the puppetmasterd and the puppetd running on 
> the same host broke down with the message:
> 
>    Could not retrieve configuration: Certificates were not trusted:
hostname 
>    not match with the server certificate
> 
> If anyone is interested in debugging this problem, I may be able to 
> arrange access to a host which is exhibiting it.

It seems to all boil down to bz 313691 [1], which in turn addresses CVE
2007-5162 [2], which makes me think that this problem will hit users of
other distros sooner or later.

The bug there is that ruby didn't verify that the common name on the
cert matched the host name to which the SSL connection was established.
In other words, you only have trouble if the CN on the cert is not the
name of the host the client connects to - often the case when your
clients connect to host 'puppet' and that is a CNAME to another host.

If my reading of post_connection_check
in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be possible to
fix this by adding 'subjectAltName' extensions to the server cert.
Changes are definitely needed in the way that the puppetmaster generates
the server cert.

David

[1] https://bugzilla.redhat.com/show_bug.cgi?id=313691 (the ticket has
some more useful references) [2]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5162

_______________________________________________
Puppet-users mailing list
Puppet-users at madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message.  Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed.  Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group.  Replies to this email may be monitored by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
------------------------------------------------------------------------