The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #10739

An initial installation of 2.7.6 results in a default certificate without alternate names

Added by Eli Klein over 2 years ago. Updated over 2 years ago.

Status:ClosedStart date:11/11/2011
Priority:NormalDue date:11/15/2011
Assignee:Josh Cooper% Done:

100%

Category:SSLEstimated time:1.00 hour
Target version:2.6.13
Affected Puppet version:2.6.12 Branch:https://github.com/puppetlabs/puppet/pull/238
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Facts around the bug:

  • Using puppet/puppet-server 2.7.6-2 RPM from the puppetlabs repo
  • CentOS 5.6
  • Stock puppet.conf

After starting the server for the first time, the certificate contains only the local hostname of the system. Here’s the openssl output from the created certificate:

[root@bld-testpuppet-01 etc]# openssl x509 -in /var/lib/puppet/ssl/certs/bld-testpuppet-01.f4tech.com.pem  -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=Puppet CA: bld-testpuppet-01.f4tech.com
Validity
Not Before: Nov 10 15:35:35 2011 GMT
Not After : Nov  9 15:35:35 2016 GMT
Subject: CN=bld-testpuppet-01.f4tech.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:bb:0c:aa:c3:73:ed:1a:30:65:83:f9:78:18:9e:
81:00:fa:32:b1:32:35:0d:c4:97:a2:93:18:8c:3f:
ee:4b:37:e1:e7:49:ec:bb:dc:0e:85:b2:3b:41:de:
58:aa:58:25:e0:a2:06:df:2e:7e:e1:2d:33:05:a2:
45:3c:17:3f:12:7a:70:58:7b:e7:ce:13:dc:c1:fa:
1e:8a:5f:d1:5c:6a:9b:9c:cb:cb:1a:35:09:07:d9:
25:31:b9:81:27:1b:44:55:7f:3f:2e:12:d5:da:29:
79:d1:15:09:22:b6:a0:04:62:12:73:80:88:81:b3:
fb:41:22:99:34:04:a5:5c:a1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier: 
22:C8:D0:C9:4F:9D:BD:69:58:FB:9B:0F:91:AE:E4:65:6B:86:5A:DC
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Netscape Comment: 
Puppet Ruby/OpenSSL Internal Certificate
X509v3 Extended Key Usage: critical
TLS Web Server Authentication, TLS Web Client Authentication
Signature Algorithm: sha1WithRSAEncryption
04:ce:b2:07:2c:3f:d0:de:03:6f:0f:db:7d:06:b2:37:1a:1a:
8f:e4:b5:56:98:fa:1d:a1:81:56:d6:ad:7a:f8:3e:41:3e:0b:
56:32:4f:67:de:99:77:82:59:8b:a3:67:53:19:0f:b4:9e:24:
38:79:5b:0b:e3:87:9a:cb:e3:4e:61:db:a7:9a:f8:98:3c:24:
0e:37:3b:2d:02:9b:dd:6d:64:c2:09:7e:0e:7f:4c:43:38:58:
c6:e0:f3:dc:07:70:d2:49:31:c3:e6:f8:f4:f7:35:8a:f4:b8:
f4:7e:e7:37:fb:d0:c4:42:8b:be:3f:f3:8c:c4:42:1f:ab:e8:
19:14
-----BEGIN CERTIFICATE-----
MIICazCCAdSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADAyMTAwLgYDVQQDDCdQdXBw
ZXQgQ0E6IGJsZC10ZXN0cHVwcGV0LTAxLmY0dGVjaC5jb20wHhcNMTExMTEwMTUz
NTM1WhcNMTYxMTA5MTUzNTM1WjAnMSUwIwYDVQQDDBxibGQtdGVzdHB1cHBldC0w
MS5mNHRlY2guY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7DKrDc+0a
MGWD+XgYnoEA+jKxMjUNxJeikxiMP+5LN+HnSey73A6FsjtB3liqWCXgogbfLn7h
LTMFokU8Fz8SenBYe+fOE9zB+h6KX9Fcapucy8saNQkH2SUxuYEnG0RVfz8uEtXa
KXnRFQkitqAEYhJzgIiBs/tBIpk0BKVcoQIDAQABo4GbMIGYMAwGA1UdEwEB/wQC
MAAwHQYDVR0OBBYEFCLI0MlPnb1pWPubD5Gu5GVrhlrcMA4GA1UdDwEB/wQEAwIF
oDA3BglghkgBhvhCAQ0EKhYoUHVwcGV0IFJ1YnkvT3BlblNTTCBJbnRlcm5hbCBD
ZXJ0aWZpY2F0ZTAgBgNVHSUBAf8EFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJ
KoZIhvcNAQEFBQADgYEABM6yByw/0N4Dbw/bfQayNxoaj+S1Vpj6HaGBVtatevg+
QT4LVjJPZ96Zd4JZi6NnUxkPtJ4kOHlbC+OHmsvjTmHbp5r4mDwkDjc7LQKb3W1k
wgl+Dn9MQzhYxuDz3Adw0kkxw+b49Pc1ivS49H7nN/vQxEKLvj/zjMRCH6voGRQ=
-----END CERTIFICATE-----

Note the missing entry similar to the following:

        X509v3 Subject Alternative Name: 
            DNS:puppet, DNS:bld-testpuppet-01.f4tech.com, DNS:puppet.f4tech.com

Adding in the dns_alt_names keyword to the config with the additional names results in the correct certificate after it’s regenerated.

Please let me know if you need further information. I’ve been able to reproduce this 3 times on freshly installed systems.


Related issues

Related to Puppet - Bug #2848: Certdnsnames apply during certificate signing rather than... Closed 11/22/2009

History

#1 Updated by Kelsey Hightower over 2 years ago

This change is related to the following security issue:

http://puppetlabs.com/security/cve/cve-2011-3872/

A bug in Puppet 0.24.0 through 2.7.5 causes Puppet to insert the puppet master’s DNS alt names 
("certdnsnames" in puppet.conf) into the X.509 Subject Alternative Name field of all certificates, 
rather than just the puppet master’s certificate.

#2 Updated by Kelsey Hightower over 2 years ago

  • Status changed from Unreviewed to Investigating
  • Assignee set to Kelsey Hightower

#3 Updated by Kelsey Hightower over 2 years ago

  • Due date set to 11/15/2011
  • Status changed from Investigating to Closed
  • % Done changed from 0 to 100
  • Estimated time set to 1.00

Eli,

I am providing you a link to our docs that provide more detail as to why certdnsname is no longer used: certdnsname

The certdnsnames setting is no longer functional, after CVE-2011-3872. We ignore the value completely.
For your own certificate request you can set dns_alt_names in the configuration and it will apply locally.
There is no configuration option to set DNS alt names, or any other subjectAltName value, for another nodes
certificate. Alternately you can use the --dns_alt_names command line option to set the labels added while
generating your own CSR.

#4 Updated by Jeff McCune over 2 years ago

  • Category set to SSL
  • Status changed from Closed to Needs Decision
  • Assignee changed from Kelsey Hightower to Nigel Kersten

Confirmed

Kelsey, I’m re-opening this and handing it to Nigel to target. I’ve confirmed there is a change in behavior we did not intend to change as part of the CVE fix.

The expected behavior is that in the default case (certdnsnames and dns_alt_names remain at their default, unset, values) there will be no change in the behavior of pre-cve and post-cve Puppet versions. That is to say, out of the box puppet master --no-daemonize --verbose should generate a certificate that works with the name “puppet” and “puppet.$(facter domainname)”.

I’ve confirmed this is not the case in Puppet 2.7.7 on a CentOS 5 machine using the system ruby runtime.


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=Puppet CA: pe-centos5.localdomain
        Validity
            Not Before: Nov 27 01:57:10 2011 GMT
            Not After : Nov 26 01:57:10 2016 GMT
        Subject: CN=pe-centos5.localdomain
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c1:bd:73:07:4b:7b:1f:82:f2:8f:14:4e:ef:67:
                    f5:71:50:aa:ec:3b:3b:e3:11:74:71:92:08:86:d5:
                    33:8b:0d:a1:aa:88:8d:de:6f:de:fa:c2:4f:d9:b1:
                    54:ca:3c:d5:6d:22:92:55:fa:92:50:84:34:04:59:
                    c3:72:cc:ff:e0:47:d6:19:5e:14:11:53:13:e2:09:
                    45:3e:92:f7:46:b5:4f:49:97:c1:99:37:30:6f:64:
                    d4:65:31:50:b1:23:81:59:cc:65:65:96:ad:44:21:
                    a6:e8:88:eb:eb:e2:b7:52:16:42:56:95:b0:64:0a:
                    b1:28:26:78:b9:c8:c6:b6:97
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                54:EF:C9:00:F2:F7:6C:DB:C2:3D:A6:07:8E:C7:56:D9:98:97:79:21
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Netscape Comment: 
                Puppet Ruby/OpenSSL Internal Certificate
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication, TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption
        c1:06:a2:ec:37:b4:38:3d:42:b3:05:ed:43:9f:eb:f4:8a:9a:
        ba:ce:28:e8:26:a7:7f:d3:1f:4a:1d:25:0c:d7:03:0c:35:d8:
        e4:d8:e3:10:f9:ae:54:13:70:0b:b0:f7:1f:27:94:20:94:00:
        5a:71:ad:fb:b0:9c:23:c5:25:32:13:4a:8a:72:6b:53:a2:e2:
        f9:f7:8c:c4:06:17:ab:c9:6a:a0:9b:4e:fb:7a:b4:98:7f:d1:
        43:9e:ce:3f:f6:9f:1c:d3:a8:df:52:39:c2:7d:ce:59:6c:a0:
        22:47:da:9c:31:4c:08:82:68:9e:84:c8:d9:a3:6e:b6:55:e7:
        cc:3b

#5 Updated by Nigel Kersten over 2 years ago

Adding Daniel P and Nick L as watchers. Is there something we’ve missed here?

#6 Updated by Nick Lewis over 2 years ago

It seems like the issue here is pretty clear cut. We simply no longer add implicit alt names (ever), and it turns out we actually want to. We already have a special case to allow alt names when generating the initial master’s cert, so it shouldn’t be particularly complex to also add some alt names in that same case (although the CSR has already long-since been created at that point, which is a bit of a complication).

#7 Updated by Josh Cooper over 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee changed from Nigel Kersten to Josh Cooper
  • Target version set to 2.7.x

#8 Updated by Nigel Kersten over 2 years ago

  • Target version changed from 2.7.x to 2.6.x

This needs to go into 2.6 and 2.7, but not earlier releases.

#9 Updated by Josh Cooper over 2 years ago

Adding default subjectAltNames was removed in commit:bab9310d2800dd3c24e002f9d85c808ee38c9d3c

   # We're a normal server.
-  def add_server_extensions
-    @basic_constraint = "CA:FALSE"
-    dnsnames = Puppet[:certdnsnames]
-    name = @name.to_s.sub(%r{/CN=},'')
-    if dnsnames != ""
-      dnsnames.split(':').each { |d| @subject_alt_name << 'DNS:' + d }
-      @subject_alt_name << 'DNS:' + name # Add the fqdn as an alias
-    elsif name == Facter.value(:fqdn) # we're a CA server, and thus probably the server
-      @subject_alt_name << 'DNS:' + "puppet" # Add 'puppet' as an alias
-      @subject_alt_name << 'DNS:' + name # Add the fqdn as an alias
-      @subject_alt_name << 'DNS:' + name.sub(/^[^.]+./, "puppet.") # add puppet.domain as an alias
-    end
-    @key_usage = %w{digitalSignature keyEncipherment}
-    @ext_key_usage = %w{serverAuth clientAuth emailProtection}
+  def self.build_server_extensions
+    {
+      "keyUsage"         => [%w{digitalSignature keyEncipherment}, true],
+      "extendedKeyUsage" => [%w{serverAuth clientAuth emailProtection}, true],
+      "basicConstraints" => ["CA:FALSE", true],
+    }

Fortunately, only the master cert needs to be regenerated, but not the CA nor any of the agents.

#10 Updated by Josh Cooper over 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Affected Puppet version changed from 2.7.6 to 2.6.12
  • Branch set to https://github.com/puppetlabs/puppet/pull/238

Note this issue needs to be merged into 2.6.x and then merged forward to 2.7.x.

Prior to #2848 (CVE-2011-3872), if Puppet[:certdnsnames] was not set,
puppet would add default subjectAltNames to any non-CA cert it signed,
including agent certs. The subjectAltNames were of the form:

  DNS:puppet, DNS:<fqdn>, DNS:puppet.<domain>

The fix for #2848, prevented subjectAltNames from ever being
implicitly added at signing time. But during this change, the default
subjectAltNames behavior was accidentally removed.

This commit restores the 'defaulting' behavior that existed
previously, but only when bootstrapping the initial master.
Additionally, default subjectAltNames are only ever added when
generating the master's certificate signing request, not at signing
time. This is important, because it ensures all subjectAltNames
originate from the CSR and are subject to our internal signing policy.

The code now requires that all of the following be true in order to
add default subjectAltNames to the CSR:

 1. We are a CA and master
 2. We're signing the master's cert, not self-signing the CA
 3. The CSR is for the current host
 4. No subjectAltNames have been specified, e.g. Puppet[:dns_alt_names]
 5. The master can resolve its fqdn

These should only ever be true when bootstrapping the initial
master. In particular, it should never be true for the CA's
self-signed cert, for remote agents, or for servers that are either
masters or CAs, but not both.

The fqdn requirement existed previously, and so the same behavior has
been restored.

Note if Puppet[:dns_alt_names] are specified when bootstrapping the
master, then we do not merge the default options -- it's either one of
the other, but not both.

#11 Updated by Josh Cooper over 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

#12 Updated by Matthaus Owens over 2 years ago

  • Target version changed from 2.6.x to 2.6.13

released in 2.6.13rc1

#13 Updated by Matthaus Owens over 2 years ago

  • Status changed from Merged - Pending Release to Closed

also released in 2.7.8rc1

Also available in: Atom PDF