Overview of a Puppet Split CA architecture

The Puppet Master CA is the only Certificate Authority (CA) in the whole infrastructure. It issues certificates for all Puppet agents. It also manages the Puppet Master systems.

The Puppet Masters are only responsible for compiling catalogs requested by Puppet Agents - they don't act as CA themselves. They only accept Puppet Agents which certificates have been issued by the Puppet Master CA.

The Puppet Agent retrieves their certificates from the Puppet Master CA the first time they run. They connect to the Puppet Masters afterwards to get their catalogs. They won't contact the Puppet Master CA anymore.

Puppet Master CA

The Puppet Master CA manages all Puppet Masters. In particular it distributes its own Certificate Revocation List (CRL) file to every Puppet Master. The Puppet Master CA also issues certificates to Puppet Agents.

Puppet Master

A Puppet Master runs under Apache and Passenger. Apache ssl module is configured to require certificates signed by the Puppet Master CA (/etc/apache2/site-available/puppetmaster):

# Require certificates to be valid
SSLVerifyClient require
SSLVerifyDepth  1

The Puppet Master is also configured to not act as a Puppet CA (/etc/puppet/puppet.conf):

[main]
ca = false

Puppet Agent

Puppet Agents retrieve their certificate from the Puppet Master CA and request their catalog from one of the Puppet Masters (/etc/puppet/puppet.conf):

[agent]
ca_server = PUPPET_MASTER_CA
server = PUPPET_MASTER

Conclusion

From a security perspective setting the SSLVerifyClient option to require increases the protection of Puppet Masters from unknown requests and revoked Puppet Agents. Having the Puppet Master CA manage the Puppet Masters also facilitates the distribution of the Puppet Master CA CRL.

On the reliability front new systems won't be added to the infrastructure if the Puppet Master CA is unavailable. However existing Puppet Agents are still functional as long as they can connect to a Puppet Master.