The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Certdnsnames apply during certificate signing rather than CSR creation
|Affected Puppet version:||0.25.1||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
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
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.
#4 Updated by Luke Kanies over 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.
#9 Updated by Dan Bode over 5 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?
#13 Updated by Radosław Antoniuk over 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.