| Good questions. It is not a supported configuration according to https://puppet.com/docs/puppet/6.2/config_ssl_external_ca.html#supported-external-ca-configurations. But we added the ssl_client_ca_auth and ssl_server_ca_auth settings in Puppet 3, largely to work around the "locacacert can only contain a single cert" issue. See https://github.com/puppetlabs/puppet/pull/916. And the ssl_client_ca_auth setting still "works" on the agent if set. As in you can point the agent to a CA bundle file, and the agent will use that to verify the server's cert chain. The ssl_server_ca_auth setting did the same for webrick puppetmaster (controlling which client intermediates the server would accept), but the setting is now dead. Now that CA bundles are fully supported, I think we should deprecate ssl_client_ca_auth and ssl_server_ca_auth. I think there are good reasons for using different intermediates, mainly around compartmentalization. If the client intermediate CA is compromised, then it doesn't affect the status of the puppetserver(s) cert. It also makes it possible to have different CRLs for server vs clients, like the infra CRL. In order to truly support different intermediates, the client should send its entire chain in its Certificate message. It appears there's a ruby bug that prevents us from being able to configure that. See https://bugs.ruby-lang.org/issues/9758. The current workaround is add the client's intermediates to the server, so it can resolve the chain, using the Jetty equivalent of https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcacertificatefile. |
