Basic autosigning (autosign.conf)

In basic autosigning, the CA uses a config file containing an allowlist of certificate names and domain name globs. When a CSR arrives, the requested certificate name is checked against the allowlist file. If the name is present, or covered by one of the domain name globs, the certificate is autosigned. If not, it's left for a manual review.

Enabling basic autosigning

The autosign.conf allowlist file’s location and contents are described in its documentation.

Puppet looks for autosign.conf at the path configured in the [autosign setting] within the [server] section of puppet.conf. The default path is $confdir/autosign.conf, and the default confdir path depends on your operating system. For more information, see the confdir documentation.

If the autosign.conf file pointed to by the autosign setting is a file that the Puppet user can execute, Puppet instead attempts to run it as a custom policy executable, even if it contains a valid autosign.conf allowlist.

In open source Puppet, no autosign.conf file exists by default. In Puppet Enterprise, the file exists by default but might be empty. In both cases, the basic autosigning feature is technically enabled by default but doesn’t autosign any certificates because the allowlist is effectively empty.

The CA Puppet primary server therefore doesn’t autosign any certificates until the autosign.conf file contains a properly formatted allowlist or is a custom policy executable that the Puppet user has permission to run, or until the autosign setting is pointed at an allowlist file with properly formatted content or a custom policy executable that the Puppet user has permission to run.

Security implications of basic autosigning

Basic autosigning is insecure because any host can provide any certname when requesting a certificate. Use it only when you fully trust any computer capable of connecting to the Puppet primary server.

With basic autosigning enabled, an attacker who guesses an unused certname allowed by autosign.conf can obtain a signed agent certificate from the Puppet primary server. The attacker could then obtain a configuration catalog, which can contain sensitive information depending on your deployment’s Puppet code and node classification.