Page MenuHomePhabricator

Puppet CA rollover
Closed, InvalidPublic


We'll need to rollover the Puppet CA mostly to switch to 2k certs and unblock general usage of host certs for high traffic applications. Open questions:

  • is there a smarter way for CA rollover and how to do it?
  • details needed on how puppet manages the CA
  • puppet management of the CA, how much is it embedded?
  • can puppet generate/add SANs

Event Timeline

fgiunchedi created this object with visibility "Custom Policy".
fgiunchedi changed the visibility from "Custom Policy" to "Public (No Login Required)".Nov 23 2016, 5:03 PM

Be wary of T150058 and Elastic's use of this CA

And also of T111654 for MariaDB's usage of this CA. Adding DBA

There are other systems using this CA, namely etcd.

I would suggest the right course of action for all apps is:

  1. create a new CA key/cert
  2. Install it as a trusted CA on all live systems
  3. Audit how applications use the puppet cert, most will just need a rolling restart once we're done
  4. Do the CA rollout for puppet. We did this in the past, details on how it was done here but I think there are simpler ways to do it
  5. Once puppet has run everywhere, new signed certs will be available; we should check which applications will need a restart and which will not. Since both the old and the new CA will be trusted, nothing should stop working.
  6. Remove the old CA once we're done

Also re: the rollover, we should switch to deploying multiple CA certificates. This would also avoid refresh problems during rollover (e.g. /etc/ssl/certs not being updated in T150058 and T145609)

fgiunchedi triaged this task as Medium priority.Nov 30 2016, 1:15 AM

IIRC we did a "rollover" (extend certificate expiration, keeping the private key) for puppet CA, resolving this old task