Puppet

1

# 2007-006-RubySSL Security Patch

2

1

3

1

## Summary

4

1

5

1

The Ruby maintainers have changed the behaviour of how Ruby handles

6

1

SSL connections. This change has affected the behaviour of Puppet,

7

1

as Puppet heavily relies on SSL connections between the puppetd

8

1

client and the puppetmaster server.

9

1

10

1

Changed versions of Ruby now validate, by default, the remote

11

1

server's certificate matches the request string passed to

12

1

Net::HTTPS. Many puppet users do not have a certificate for the

13

1

puppetmaster which matches its DNS string, causing an exception to

14

1

be thrown by the new Net::HTTPS implementation.

15

1

16

1

Please direct questions to the puppet-users mailing list, after

17

1

reading this document fully.

18

1

19

1

## References

20

1

21

1

-   [Security Advisory](http://www.isecpartners.com/advisories/2007-006-rubyssl.txt)

22

1

-   [Net::HTTPS Vulnerability Advisory](http://www.ruby-lang.org/en/news/2007/10/04/net-https-vulnerability/)

23

1

-   [Ruby Trunk Checkin 13499](http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=13499)

24

1

-   [Ruby Trunk Checkin 13500](http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=13500)

25

1

-   [#896](/trac/puppet/ticket/896 "defect: Need subjectAltName in Server Cert; newer Ruby SSL check barfs if hostname ... (closed: fixed)")

26

1

    - Need subjectAltName in Server Cert; newer Ruby SSL check barfs if

27

1

    hostname on SSL connection != CN on cert

28

1

-   [Puppet-Users Main Thread](http://mail.madstop.com/pipermail/puppet-users/2007-November/005097.html)

29

1

-   [Puppet-Users Discussion](http://mail.madstop.com/pipermail/puppet-users/2007-November/005234.html)

30

1

-   [DSA 1410-1](http://lists.debian.org/debian-security-announce/debian-security-announce-2007/msg00189.html)

31

1

-   [DSA 1411-1](http://lists.debian.org/debian-security-announce/debian-security-announce-2007/msg00190.html)

32

1

33

1

## Platforms Affected

34

1

35

1

-   RHEL 5.1 (As of 2007-11-20)

36

1

-   Fedora 8 (As of 2007-11-20)

37

1

-   Debian etch (As of 1.8.5-4etch1, released on 2007-11-25)

38

1

-   Ubuntu

39

1

40

1

## Symptoms and Errors

41

1

42

1

Many people report receiving:

43

1

44

1

    Certificates were not trusted: hostname was not match with the server certificate

45

1

46

1

or with older ruby (1.8.2)

47

1

48

1

    Certificates were not trusted: hostname not match

49

1

50

1

## Workarounds

51

1

52

1

Until Puppet is patched (See

53

1

[#896](/trac/puppet/ticket/896 "defect: Need subjectAltName in Server Cert; newer Ruby SSL check barfs if hostname ... (closed: fixed)"))

54

1

to quickly work around this problem you have two options. You may

55

1

choose to address this server side, by re-creating the

56

1

puppetmasterd certificate, or client-side by specifying the FQDN of

57

1

the puppetmaster.

58

1

59

1

### Server Side

60

1

61

1

You may re-create a certificate for your puppetmasterd server which

62

1

matches the value passed to the --server configuration option of

63

1

puppet. This defaults to --server=puppet, and many sites set their

64

1

puppetmaster's fully qualified domain name to

65

1

puppet.yourdomain.com.

66

1

67

1

Therefore, if you run puppetd in the default configuration, issue a

68

1

new certificate signed by the puppetmaster CA with a commonName of

69

1

"puppet". This can be accomplished by:

70

1

71

1

1.  Stopping puppetmasterd

72

1

2.  Editing puppet.conf so that in the [puppetmasterd] section, the

73

1

    certname is specified. Note: you may have to create the

74

1

    [puppetmasterd] section if it isn't there already:

75

1

        [puppetmasterd]

76

1

                certname=puppet

77

1

78

1

3.  Starting puppetmasterd. The new certificate will be created

79

1

    when puppetmaster starts.

80

1

81

1

You need to make sure that all connections from clients to the

82

1

puppetmaster now use that certname - one place where that is often

83

1

not the case is in puppet: URL's in your manifests, especially with

84

1

URL's that use $servername. You can address that very simply by

85

1

making sure that all such URL's do not have an explicit server in

86

1

them, i.e. that they are puppet:///path/components. For such URL's,

87

1

the puppet client fills in the correct server name automatically.

88

1

89

1

### Client Side

90

1

91

1

If your server certificate contains the FQDN in the CN field,

92

1

another solution is to change your puppet.conf to reference the

93

1

FQDN of the puppetmaster in the server parameter:

94

1

95

1

    [puppetd]

96

1

    # Make sure all log messages are sent to the right directory

97

1

    # This directory must be writable by the puppet user

98

1

    pluginsync=true

99

1

    factsync=false

100

1

    report=true

101

1

    server=kakapo.mydomain

102

1

103

1

You may check the server certificate like so:

104

1

105

1

    openssl s_client -showcerts -connect puppet:8140

106

1

107

1

Look for subject=/C=US/ST=Ohio/O=The Ohio State

108

1

University/OU=Department of

109

1

Mathematics/CN=puppet.math.ohio-state.edu

110

1

111

1

If the CN value matches the fqdn of the host, the ruby DNS checks

112

1

will pass.

113

1

114

1

Additionally make sure any fileserver calls and filebucket calls in

115

1

your manifests reference the FQDN.

116

1

117

1

This change will satisfy the validation checks added to Ruby.

Ruby Ssl 2007 006