Issue #7272 has been updated by Trevor Vaughan.
I think that this should be part of autosign.conf. Reasoning: 1) If you don't want to autosign, you don't want to auto-resign. 2) It's completely related functionality. Perhaps something like adding an integer field after the autosign parameter that will denote the number of days prior to expiration that you resign? What happens in the case of a laptop that's been off of the network for months and re-joins? You almost need some method for the server and client to work out that it had a valid certificate and is now being re-signed. Also related: What happens when the CA certificate expires? All of these items should be automated IMO. ---------------------------------------- Feature #7272: Puppet should allow for *automatic resigning* of SSL certs https://projects.puppetlabs.com/issues/7272 Author: Matt Wise Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Since Puppet acts as an SSL 'factory' anyways, it should be a bit more full featured and offer a resigning capability to existing validated clients. In our environment we've cobbled together a system where the clients check regularly that their SSL cert is still valid. If its going to be not-valid within X days, they start checking in with a CGI script on the puppet ca master. When they connect, they supply their original CSR (found in /var/lib/puppet) and the CGI script handles some validation of that CSR, and then signs a new certificate with that data. This is a kludge that should be built into Puppet. I propose the following workflow.. 1) Puppet Agent runs... before even connecting to the server, it determines whether or not its SSL certificate is going to expire within XX days. If it is ... 2) Puppet agent supplies original CSR (thats still in /var/lib/puppet) to puppet ca server, and requests a resigning. If resigning is enabled on the puppet server ... 3) Puppet server resigns the cert, deletes the old cert and immediately invalidates its serial #. Server then passes the new Cert back to the client... 4) Client re-starts essentially with the new cert and begins its real puppet run. This functionality allows for Puppet certs to be extremely short-lived... you could actually let certs expire after as little as a day or two if you wanted, and Puppet would handle all of the resigning. Any client that 'doesnt check in' would simply have its cert expire, and would have to be fixed manually. (ps, i think its critical that the client resupplies the CSR to the server.. rather than the ca server looking for the original CSR. this allows for multiple puppet ca servers, which is pretty critical in large environments) (pps, the only reason we havnt finished our migration to a multi-ca-master environment is the CRL... ideally if i could tell each of my puppet masters about the others, they could all keep their CRLs in-sync with eachother) -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
