So, that's a verified "no, the actual issue isn't going to be addressed without compatibility issues?"
Just trying to plan. Thanks, Trevor On Tue, May 22, 2012 at 5:10 PM, <[email protected]> wrote: > Issue #7272 has been updated by Jeff McCune. > > For what it’s worth, we’re planning to address the initial certificate > problem as part of the capabilities we need in place for the upcoming Sites > work. > > There’s a discussion about Sites and the need to simplify the initial key > signing process on the puppet users mailing list: > > https://groups.google.com/group/puppet-users/browse_thread/thread/eb1d4534989595dd/e0e20cfc14f79248?lnk=gst&q=PSK#e0e20cfc14f79248 > > We mentioned “PSK” but we’re not planning to implement a pre-shared key > model. Instead we’ve been thinking of this as some capability to simplify > the existing trusted third party public key model. > > -Jeff > > ________________________________ > > Feature #7272: Puppet should allow for *automatic resigning* of SSL certs > > Author: Matt Wise > Status: Accepted > Priority: Normal > Assignee: > Category: SSL > Target version: 3.x > 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 -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
