History

2007-006-RubySSL Security Patch

Summary

The Ruby maintainers have changed the behaviour of how Ruby handles SSL connections. This change has affected the behaviour 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 the puppetmaster which matches its 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

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)
  • Ubuntu

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:

  1. Stopping puppetmasterd

  2. 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

  3. 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.