Issue #2848 has been updated by Luke Kanies. 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. ---------------------------------------- Bug #2848: Certdnsnames apply during certificate signing rather than CSR creation http://projects.reductivelabs.com/issues/2848 Author: Atha Kouroussis Status: Investigating Priority: Normal Assigned to: Markus Roberts Category: SSL Target version: 0.25.2 Affected version: 0.25.1 Keywords: Branch: 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) <pre> [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 </pre> h3. Second level (puppet masters) <pre> [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 </pre> h3. Third level (puppet client) <pre> [main] ca_server = puppeteer.domain.com [puppetd] server = puppet.domain.com </pre> 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: <pre> 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 </pre> 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! <pre> puppetca --print puppetter-hostname.domain.com puppeer-hostname.domain.com ... X509v3 Subject Alternative Name: DNS:puppeteer.domain.com, DNS:puppeteer-hostname.domain.com ... </pre> <pre> 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 ... </pre> <pre> 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 ... </pre> 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
