Issue #3143 has been updated by Jeff McCune.
As another update to the world, here is my take on this. Basically, I think we need to add a bunch more settings that line up with Apache's model of SSL servers and SSL clients. (They call them Proxies since they're a web server.) # 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. ---------------------------------------- Feature #3143: Puppet should correctly support CA trust chains https://projects.puppetlabs.com/issues/3143#change-66515 Author: Justin Baugh Status: Accepted Priority: High Assignee: Category: SSL Target version: 3.x Affected Puppet version: 0.25.3 Keywords: Branch: It would be very, very useful for Puppet to use existing enterprise-deployed PKI systems, rather than relying somewhat on the creation of its own self-signed CA. Here is some background: For a few months, I have been using 0.24.8 in production. I used the techniques described in the wiki (multiple CA certificates) to override the local CA certificate, setting localcacert in puppet.conf to the PEM bundle. This required a slight hack to prevent Puppet from overwriting the file, but it worked and verified correctly. My PKI setup is fairly simple: I have a global root, which has a subordinate network CA, which has signed the Puppet CA (A->B->C). I have recently upgraded to 0.25.4 and this has broken entirely (see http://pastebin.ca/1776458 for a client debug; the server side never sees the request because it doesn't even get that far). I have tried both with a brand new client and an upgrade of an existing one - the errors are the same, failure to validate certificates. >From looking at cert_setup in network/http_pool.rb, Puppet will set the >ca_file and SSL store as appropriate, but neither of these are seemingly >sufficient to verify a trust chain. However, when I commented out usage of the >certificate store and CA file (http://pastebin.ca/1776467) and used ca_path >instead (set to an OpenSSL-hashed cert dir) containing A,B, and C's PEM files, >the verification succeeds, which confuses me greatly. I also tried directly modifying the certificate store passed to the http object to load my certificates directly into the store (via add_file) and this also does not verify. I notice that WEBrick deals with this issue by modifying the SSL context directly (extra_chain_cert). Is it possible for Puppet to do something similar? The property is not directly exposed from http.rb. When I have done testing with Puppet using WEBrick, modifying the appropriate WEBrick code to set the property to the appropriate trust chain (A and B) also works correctly, allowing the verification to succeed. I apologize in advance if if I am overlooking something or doing it wrong. In addition, I am happy to diagnose/debug/investigate this issue, if it is helpful, and write a patch for it if necessary, but my ruby/ruby openssl familiarity is minimal. -- 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.
