2007-006-RubySSL Security Patch
Summary
The ruby maintainers have changed the behavior of how Ruby handles SSL connections. This change has affected the behavior of puppet, as puppet heavily relies on SSL connections between the puppetd client and the puppetmaster server.
Changed versions of Ruby now validate, by default, the remote server's certificate matches the request string passed to Net::HTTPS. Many puppet users do not have a certificate for puppetmaster which matches it's DNS string, causing an exception to be thrown by the new Net::HTTPS implementation.
Please direct questions to the puppet-users mailing list, after reading this document fully.
References
- Security Advisory
- Net::HTTPS Vulnerability Advisory
- Ruby Trunk Checkin 13499
- Ruby Trunk Checkin 13500
- #896 - Need subjectAltName in Server Cert; newer Ruby SSL check barfs if hostname on SSL connection != CN on cert
- Puppet-Users Main Thread
- Puppet-Users Discussion
- DSA 1410-1
- DSA 1411-1
Platforms Affected
- RHEL 5.1 (As of 2007-11-20)
- Fedora 8 (As of 2007-11-20)
- Debian etch (As of 1.8.5-4etch1, released on 2007-11-25)
Symptoms and Errors
Many people report receiving:
Certificates were not trusted: hostname was not match with the server certificate
or with older ruby (1.8.2)
Certificates were not trusted: hostname not match
Workarounds
Until puppet is patched (See #896) to quickly work around this problem you have two options. You may choose to address this server side, by re-creating the puppetmasterd certificate, or client-side by specifying the FQDN of the puppetmaster.
Server Side
You may re-create a certificate for your puppetmasterd server which matches the value passed to the --server configuration option of puppet. This defaults to --server=puppet, and many sites set their puppetmaster's fully qualified domain name to puppet.yourdomain.com.
Therefore, if you run puppetd in the default configuration, issue a new certificate signed by the puppetmaster CA with a commonName of "puppet". This can be accomplished by:
- Stopping puppetmasterd
- Editing puppet.conf so that in the [puppetmasterd] section, the certname is specified. Note: you may have to create the [puppetmasterd] section if it isn't there already:
[puppetmasterd] certname=puppet - Starting puppetmasterd. The new certificate will be created when puppetmaster starts.
You need to make sure that all connections from clients to the puppetmaster now use that certname - one place where that is often not the case is in puppet: URL's in your manifests, especially with URL's that use $servername. You can address that very simply by making sure that all such URL's do not have an explicit server in them, i.e. that they are puppet:///path/components. For such URL's, the puppet client fills in the correct server name automatically.
Client Side
If your server certificate contains the FQDN in the CN field, another solution is to change your puppet.conf to reference the FQDN of the puppetmaster in the server parameter:
[puppetd] # Make sure all log messages are sent to the right directory # This directory must be writable by the puppet user pluginsync=true factsync=false report=true server=kakapo.mydomain
You may check the server certificate like so:
openssl s_client -showcerts -connect puppet:8140
Look for subject=/C=US/ST=Ohio/O=The Ohio State University/OU=Department of Mathematics/CN=puppet.math.ohio-state.edu
If the CN value matches the fqdn of the host, the ruby DNS checks will pass.
Additionally make sure any fileserver calls and filebucket calls in your manifests reference the FQDN.
This change will satisfy the validation checks added to Ruby.
