Bug #2848
Certdnsnames apply during certificate signing rather than CSR creation
| Status: | Closed | Start date: | 11/22/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | SSL | |||
| Target version: | - | |||
| Affected Puppet version: | 0.25.1 | Branch: | ||
| Keywords: | ||||
| Votes: | 1 |
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
History
Updated by Markus Roberts over 2 years ago
- Status changed from Unreviewed to Investigating
- Assignee set to Markus Roberts
Updated by Markus Roberts over 2 years ago
- Target version set to 0.25.2
Updated by Markus Roberts over 2 years ago
- Category set to SSL
Updated by Luke Kanies over 2 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.
Updated by Luke Kanies over 2 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.
Updated by Markus Roberts over 2 years ago
- Target version set to 0.25.3
Updated by Markus Roberts over 2 years ago
- Target version changed from 0.25.3 to 0.25.4
Updated by James Turnbull over 2 years ago
- Target version changed from 0.25.4 to 0.25.5
Updated by Dan Bode about 2 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?
Updated by James Turnbull about 2 years ago
- Target version changed from 0.25.5 to 49
Updated by James Turnbull over 1 year ago
- Target version deleted (
49)
Updated by Daniel Pittman 7 months ago
- Status changed from Accepted to Closed
- Assignee set to Daniel Pittman
This has been resolved with the release of CVE-2011-3872.
Updated by Radosław Antoniuk 6 months 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.
Updated by James Turnbull 6 months ago
Please read: http://puppetlabs.com/security/cve/cve-2011-3872/