Issue #18958 has been updated by Shaun Kruger.
For what it's worth I've been concerned about maintaining my puppet installation long term because the one PKI question that appears difficult to resolve is that of signing a new CA certificate and transitioning the PKI infrastructure to that new CA when the initial puppet CA cert is about to expire. When I see an initial statement that puppet's CA is problematic and that using an external CA project is the solution I worry a little. PKI can be a complex thing and it would be a shame to make a decision that creates a dependency on additional infrastructure that may not be worth the management overhead for a lot of people. It is a lot of moving parts that still may not solve the CA cert expiration work flow. I would like to suggest how I would approach this problem myself. I am going to take the assumption that it is simple enough to create multiple CA instances on a system by storing them in separate self contained directories and that agents can be modified to try a second authentication key/cert pair if authentication fails with their main certificate. As an administrator of a puppet installation I know that my puppet root CA certificate is going to expire in soon and I would like to make a zero down time transition. In order to accomplish this I wish to take a few steps: 1. Initialize a new certificate authority and generate a new root CA cert 2. List all current certificates under the old CA 2a. For each certificate in the old CA, take the old CSR and sign it with the new CA 3. After all CSRs for current certificates have been signed by the new CA, publish the new certificates to agents as backup certificates for use when authentication fails using the primary key/cert pairs. 4. Configure puppet to use the new root CA for authorizing agents. 4a. Validate that agents are able to authenticate using the new CA. Automatic agent fallback to a backup certificate should allow this to happen without incident. 5. Signal all agents to make their backup certificate their primary certificate so that authorizations are done the way they were before the upgrade process began. 6. Deprecate/archive the old CA. In the end, the question of whether a CA is internal or external to puppet has no bearing on being able to execute this work flow which is actually the pain point I have identified with puppet's certificate authority when seeking for zero down time transitions to a new root CA. Being able to switch out puppet's internal CA key/certificate by creating a new one and transitioning to it could also allow for joining a larger PKI where the puppet CA certificate is actually signed by whatever PKI an organization has deployed. This can enable a pattern where there are multiple puppet masters each acting as subordinate certificate authorities without puppet being married to a particular PKI product. ---------------------------------------- Bug #18958: Puppet's built-in PKI is problematic https://projects.puppetlabs.com/issues/18958#change-82281 Author: eric sorenson Status: Accepted Priority: Normal Assignee: eric sorenson Category: SSL Target version: Affected Puppet version: Keywords: SSL backlog Branch: The number one user pain point in master/agent setups is SSL. Ultimately, the problem is that we've implemented a completely standalone PKI but don't have many of the affordances that a "real" PKI provides. It would be awesome to separate the certificate functionality out of the codebase so it could be implemented outside of puppet itself -- a prime target for integration is the [FreeIPA](http://freeipa.org/page/Main_Page) project which is what most open-source users who have external CAs are trying to work with. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
