Certificate Life-cycle Management about ziti HOT 2 OPEN

Edge router works for extending enrollment is done.

from ziti.

I encountered one part of the cert life-cycle topic while working out how to provide controller leaf cert renewal for the reference Linux/Docker deployment runtimes.

The question will likely arise when a controller was not initially bootstrapped manually by the same person who is facing certificate expiry.

It's not particularly urgent for most operators today because routers and edge SDKs don't enforce controller server cert expiry. I'm curious whether that's configurable for routers or SDKs, and I'm curious whether clusters of controllers do by default or can be configured to enforce client certificate expiry.

For Linux/Docker, in the context of prescribed, normalized production runtimes, enabling the controller to renew its leaf certs would also require a change of configuration schema to allow for managing the CAs that would issue those certificates. Presently, the only CA managed by Ziti is the edge signer, and there's no requirement nor assumption that all leaf certs used by the controller are issued by the edge signer, though that is an allowed scenario.

I'll propose that we do want to solve this for most operators, at least those who opt-in to automated controller bootstrapping. I'll offer two implementation sketches for discussion and a simple implementation of the workaround that avoids changing controller code.

1. Enhancement of the controller supporting operational scenarios where the responsible humans wish the controller to manage its leaf certificates and all CAs internally: they must use a single PKI for the edge signer and leaf certs presented by the controller.

   Then, assuming the edge signer CA issued at least one of the controller's leaf certs, we could add a timer to the running controller that checks leaf cert expiry and re-issues and writes the client and server certs, overwriting those nearing expiration.

   The controller would also load the new certificates into memory to present them during the next TLS negotiation.

   This "extend" operation and timer could be enabled by default for the run command or optional based on some command-line flag or config directive. I couldn't think of any downside (disfunction, astonishment, etc.) to auto-renewing leaf certs, so I'm leaning toward enabled by default. It seems most likely that the operator will appreciate not being forced to choose between manually issuing certs and not enforcing expiry in the current reality.

   Like the router's run --extend flag, the controller could support an "extend now" feature that immediately resets the renewal timer to zero. If the operator wishes to maintain a separate PKI for the control plane, web binding(s), or both, the controller would ignore and not extend those leaf certs. It would only operate on those from the edge signer CA, if any, and so it would never replace nor renew any leaf certs from another CA with one from the edge signer.

2. Workaround controller leaf cert renewal with a startup wrapper: Instead of changing the shape of the controller config and adding new operations and timers within the controller, I thought to sketch a workaround using the ziti pki command within the bootstrapping script called by the scheduler/process manager, i.e., Docker or systemd. The purpose of such wrappers is to run a simple algorithm like if no PKI then create PKI; if no config.yml then generate config.yml; if no database then init data;. Such bootstrapping is optional, and each of those three pillars of bootstrapping can be selectively toggled so that the operator may bring their own PKI, config.yml, database, or all three. In a scenario where the Linux/Docker operator has opted in to bootstrapping, this solution will re-issue the controller's leaf certs at every startup.

from ziti.