Actually, from an automation point of view, this is pretty trivial. Step 1) Create new CA (preserving old CA trust) X number of days prior to expiration Step 2) Pass out both CA trust roots to all systems Step 3) Start a re-signing party using the fact that you already have a bi-directional trust in place Step 4) Let the old CA certificate gracefully expire and remove it whenever you like (nothing will trust it anyway)
That's pretty much it. For traditional *NIX applications using a CAPath approach, this is trivial. As long as you have a valid CA in your CAPath, you can roll over certificates with ease. Trevor On Mon, Jan 9, 2017 at 9:04 PM, Rob Nelson <rnels...@gmail.com> wrote: > I think certificate handling is a valid critique of puppet's security > implementation. Running a public key infrastructure of any sort is > difficult. Things like expired CAs and a lack of intermediate signing CAs > does expose puppet administrators who are lacking those fairly rare skill > sets to some difficult potential issues. I don't want to run a CA, mostly > because I've had to run one before. Many people would also like to extend > the expiration to more than 5 years, but don't find out about this issue > until 4.5 years in. Whoops :) > > It's just that the fix isn't agents automatically accepting new CAs. In > the example given of bringing a new CA online, the issue isn't that the > client would be missing a copy of the original CA signatures, but that > there's no way to verify the new CA is related to the old CA. This > constitutes a pretty high security risk with a decent probability for > exploitation - and not just by external parties, it would be easy to DoS > your agents during a failed migration or by testing with vagrant or > additional VMs by forgetting to change DNS/IPs or a dozen other simple > things to miss. Any improvement here probably ends up being relatively > complex to ensure risks remain low. > > It would be much more reasonable to have an extremely long lived CA and > some intermediate CAs. This is supported by puppet, but only I believe with > an external CA setup (https://docs.puppet.com/puppet/latest/config_ssl_ > external_ca.html) - again, not something most of us should probably be > doing. I don't know that there's a great way to handle this for the masses, > unless Puppet wants to become a CA and sign intermediates for us ;) > > On Mon, Jan 9, 2017 at 7:18 PM John Gelnaw <jgel...@gmail.com> wrote: > >> since the agent has, in theory, a valid copy of the original CA which it >> can use to validate the connection. >> > -- > Rob Nelson > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-users/CAC76iT_2XN3vaZKrpzsrXOzkT%2B4_ > 3P82ZZWkipigm8%3D%3DXew9ZA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-users/CAC76iT_2XN3vaZKrpzsrXOzkT%2B4_3P82ZZWkipigm8%3D%3DXew9ZA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CANs%2BFoVhHTsauG_gA_fODFXWYAoj9McHuvLk5ikOC%3DoReFd35Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
