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

Bug #2848

Certdnsnames apply during certificate signing rather than CSR creation

Added by Atha Kouroussis almost 5 years ago. Updated over 1 year ago.

Status:ClosedStart date:11/22/2009
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:SSL
Target version:-
Affected Puppet version:0.25.1 Branch:
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

h2. Background

We have a three tier deployment: top level is one puppetmaster that acts as CA and as master for the second level. At the second level we have two or more load balanced puppet masters. These second level puppet masters have their CA disabled and point to ca_server to the top level puppet master. All puppet masters have the certdnsnames option set as follows:

h3. Top level (puppeteer)

[puppetmasterd]
autosign = true
autosign = /etc/puppet/autosign.conf
certdnsnames = puppeteer.domain.com

# for Passenger
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

h3. Second level (puppet masters)

[puppetmasterd]
certdnsnames = puppet.domain.com
  
# for Passenger
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

# CA
ca = false
ca_server = puppeteer.domain.com

[puppetd]
server = puppeteer.domain.com

h3. Third level (puppet client)

[main]
ca_server = puppeteer.domain.com

[puppetd]
server = puppet.domain.com

In order for this to work, we have to: * Start the puppeteer * Run puppetd on the second level puppetmasters to generate their certificates and have them signed by the puppeteer CA * Start the puppetmasterd on the second level masters

h2. Problem

The problem arises when the third level clients connect to any of the second level masters:

puppetd --test --debug
...
...
err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Investigating the issue we saw that the puppeteer CA did not apply the correct certdnsnames to the second level puppetmasters. Even worse, it applied its own aliases to ALL the certificates it signed!

puppetca --print puppetter-hostname.domain.com
puppeer-hostname.domain.com
...
X509v3 Subject Alternative Name: 
                DNS:puppeteer.domain.com, DNS:puppeteer-hostname.domain.com
...
puppetca --print any-puppet-master-hostname.domain.com
puppeer-hostname.domain.com
...
X509v3 Subject Alternative Name: 
                DNS:puppeteer.domain.com, DNS:any-puppet-master-hostname.domain.com
...
puppetca --print any-puppet-client-hostname.domain.com
puppeer-hostname.domain.com
...
X509v3 Subject Alternative Name: 
                DNS:puppeteer.domain.com, DNS:any-puppet-client-hostname.domain.com
...

We are currently working around the issue by assigning both puppeteer and puppet aliases to the puppeteer so when the certificates are generated the have both hostnames and the clients don’t complain.


Related issues

Related to Puppet - Bug #10739: An initial installation of 2.7.6 results in a default cer... Closed 11/11/2011 11/15/2011

History

#1 Updated by Markus Roberts almost 5 years ago

  • Status changed from Unreviewed to Investigating
  • Assignee set to Markus Roberts

#2 Updated by Markus Roberts almost 5 years ago

  • Target version set to 0.25.2

#3 Updated by Markus Roberts almost 5 years ago

  • Category set to SSL

#4 Updated by Luke Kanies almost 5 years ago

  • Subject changed from Puppet does not apply correct certdnsnames if not acting as CA to Certdnsnames apply during certificate signing rather than CSR creation

According to this page: http://therowes.net/~greg/2008/01/08/creating-a-certificate-with-multiple-hostnames/

We can have alternative names in the CSR, not just the cert, but Puppet can only add them to the cert.

My concern with supporting alternative names in the CSR is that it allows the client to ask for additional name aliases, which is potentially dangerous (i.e., a client could ask for domain.com, rather than a qualified hostname). IF we support names in the CSR, we’d need to add warnings in the UI to make sure people knew what they were agreeing to.

The other question is whether it’s a bug for the server to sign certs with the value of certdnsnames. Until we add names to CSRs I don’t think we can remove this behaviour, so I think it stays.

If we do add the ability for CSRs to have alternative names, we probably still want the existing behaviour, too, but we can cross that bridge when we come to it.

#5 Updated by Luke Kanies almost 5 years ago

  • Status changed from Investigating to Accepted
  • Assignee deleted (Markus Roberts)
  • Target version deleted (0.25.2)

Unscheduling this. Please let us know if you think it’s critical.

#6 Updated by Markus Roberts almost 5 years ago

  • Target version set to 0.25.3

#7 Updated by Markus Roberts almost 5 years ago

  • Target version changed from 0.25.3 to 0.25.4

#8 Updated by James Turnbull almost 5 years ago

  • Target version changed from 0.25.4 to 0.25.5

#9 Updated by Dan Bode over 4 years ago

I ran into this today.

  • load balancer with 2 puppetmasters
  • both puppetmasters use the same CA
  • both puppetmasters should be accessible either as the loadbalanced certname or their hostname

to fix this, I had to generate all of the server certs using

puppetmasterd —certname blah

on the same machine as the CA (actually I copied the ca dir to the non production machine and generated the cert there)

is there a better way to do this?

#10 Updated by James Turnbull over 4 years ago

  • Target version changed from 0.25.5 to 49

#11 Updated by James Turnbull almost 4 years ago

  • Target version deleted (49)

#12 Updated by Anonymous almost 3 years ago

  • Status changed from Accepted to Closed
  • Assignee set to Anonymous

This has been resolved with the release of CVE-2011-3872.

#13 Updated by Radosław Antoniuk almost 3 years ago

Exactly how that was “resolved” ? Please document somewhere in the wiki how puppetmaster should be configured for domain aliases, this would be very useful. I have found several issues for that but they do not contain a “preferred” way to do that with the current version.

#15 Updated by Anonymous over 1 year ago

  • Assignee deleted (Anonymous)

Also available in: Atom PDF