SERVER-345, we had some discussion about the possibility of having Puppet Server intentionally fail to startup with a meaningful error message for the case that a file at the localcacert location exists, none of the other files that the CA would generate for itself do, and the "real" Puppet certificate-authority service is enabled at startup. We decided to forego that work in the interest of getting the work for not overwriting the localcacert with the cacert done. Given that a few IRC users have encountered some confusion around this behavior, I thought I'd open a separate ticket that we can investigate further at some point.
Upon review of the PR for
SERVER-345, we decided to bail on the idea of adding :localcacert to required-ca-files as was discussed in the ticket. Doing this would have been problematic if the CA files had been pre-generated, outside puppet-server's startup process. In that scenario, it would be possible for the localcacert to not exist but for the other CA files to exist - which would have failed the required-ca-files check. I think this could still be done safely if we were to change the logic to only additionally fail if localcacert does exist but any of the other CA files did not exist at startup - given this would still seem to be an invalid scenario. Doing this would have involved a bit more logic, though.
In an external CA use case where the external CA is another Puppet CA, it's common for users to do an agent run on the new master machine before starting the actual server. The key here is that in a multi-master scenario, there is usually a 'master of masters', which is where the agents on all of the other masters are configured to point to. This is a very common deployment pattern from what I understand.
This agent run will result in certs being generated with the fqdn of the machine, and the file paths where those certs get deployed will correspond with where Puppet Server will be looking for its 'master cert' on startup. We also get a copy of the localcacert via the agent run.