Issue #15404 has been updated by Andrew Parker. Target version deleted (3.x)
I can't seem to mark this properly as a duplicate of #3143.... ---------------------------------------- Feature #15404: Fully support multiple CA's and CA trust chains in Puppet https://projects.puppetlabs.com/issues/15404#change-73309 Author: Jeff McCune Status: Duplicate Priority: Normal Assignee: Category: SSL Target version: Affected Puppet version: 0.25.0 Keywords: chain, cacert, localcacert, multipleca Branch: # Overview # Puppet has [accidentally supported multiple CA certificates](http://projects.puppetlabs.com/projects/1/wiki/Multiple_Certificate_Authorities) and CA chaining up to and including Puppet 2.7. This support has never been "official" though and has always been based on work-arounds. In order to fully support multiple certificate authorities and chains of trust Puppet needs to implement the following behaviors. All of these separate concerns are currently implemented in the localcacert behavior. Because Puppet uses a single self-signed CA certificate by default, a single settings to control these concerns makes sense. To fully support CA chaining and separate CA's, however, we need the ability to separate out of the concerns of the localcacert setting. ## Distinguish between client and server certificates ## The default behavior of Puppet in 2.7 and previous versions is to create a single self signed CA certificate and use this certificate to issue all other certificates. All certificates issued by the Puppet CA are marked for client and server usage. This means a SSL certificate issued to a Puppet agent is able to be re-used as a SSL server certificate. This is a potential security risk as every agent possesses a signed certificate that could be used to serve up configuration catalogs to other agents. First and foremost, all SSL certificates ## Distinguish between client and server SSL settings ## Puppet is different from the traditional HTTPS model of SSL certificates in that both peers mutually authenticate each other using x.509 trust chains. In Puppet 2.7 and earlier the configuration options only allow a single CA certificate to be used for both sides of this handshake. This is the localcacert option. If we are to fully support multiple CA's then we need to expose the ability to configure Puppet agent's and Puppet master's with different trusted CA certificates. For example, I may want to issue all client (agent) certificates using the CA named "Puppet Agent Signing CA." Similarly, I may want to issue all server (master) SSL certificates using a CA named "Puppet Master Signing CA" In this situation, I could simply point the localcacert setting for agents at one file and the localcacert setting for masters at another file but this poses a problem for the agent process running on the master itself. To disambiguate this situations I think we need configuration settings such as "ssl_client_cacert" and "ssl_server_cacert" ## Distinguish between trusted certificates and authenticating certificates ## When building a certificate chain we need to distinguish between CA certificates we trust and CA certificates we trust to authenticate peer connections. The [Apache SSL documentation](http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#SSLCertificateChainFile) describes the situation pretty well: <blockquote> This directive sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of of the server certificate and can range up to the root CA certificate. Such a file is simply the concatenation of the various PEM-encoded CA Certificate files, usually in certificate chain order. </blockquote> <blockquote> This should be used alternatively and/or additionally to SSLCACertificatePath for explicitly constructing the server certificate chain which is sent to the browser in addition to the server certificate. **It is especially useful to avoid conflicts with CA certificates when using client authentication. Because although placing a CA certificate of the server certificate chain into SSLCACertificatePath has the same effect for the certificate chain construction, it has the side-effect that client certificates issued by this same CA certificate are also accepted on client authentication. That's usually not one expect.** </blockquote> ## Support verification depth ## As soon as we officially support certificate chains, we need to tune how many intermediate certification authorities can be used to "fill in" the gap from a known authentic CA to a SSL certificate. This could default to a reasonable number (5-7?), but should probably be greater than 1 and less than 10. It should definitely be end-user tunable though. -- 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://projects.puppetlabs.com/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.
