Cluster vs. server certificates and PKI

Trying to get more specific questions to address my Incus, PKI, and Step CA post, while thinking about Incus in terms of short-lived certs from Step CA.

I haven’t checked the default certs created by incus admin init for a standalone or clustered server setup. Given that the cluster cert is documented as having a 10-year expiration, it’s possible the default server certs are long-lived, as well. I realize that I may be swimming upstream here by wanting to use short-lived certs.

According to the docs, the cluster certificate:

  • needs to be the same on all member servers
  • defaults to a self-signed certificate with a 10-year expiration
  • is updated on all member servers with the incus cluster update-certificate command
  1. Does “cluster.crt”
    1. use the “server.ca” CA bundle for existing PKI, if present?
    2. use its own “cluster.ca” bundle for PKI?
    3. something else?
  2. If something like step CLI updates the cluster certificate, should that immediately be followed by an incus cluster update-certificate command? (If so, I think this could be incorporated into Smallstep’s automated renewal recommendations, using a systemd override.conf.)
  3. Since all cluster members would have the same cluster cert and it would thus expire for all of them, is there any recommended mechanism for making sure only one member updates the cluster cert and runs incus cluster update-certificate, while preserving the capability for other member(s) to take over that responsibility if necessary? Renewals could potentially happen frequently with short-lived certs from Step CA.
  4. For clarification, does incus cluster update-certificate handle all the communication and distribution to copy the cluster cert to all members? Does this include the entire PKI setup (i.e. the CA bundle)?
  5. Using the ACME server config, is it possible to get both server and cluster certificates (such as from a local Step CA certificate authority)? (I’m trying to make sure this is for “upstream” from the server/cluster, not ACME “downstream” for instances hosted on the server/cluster.)
  6. For ACME with short-lived certs for the server and/or cluster, will Incus automatically renew them and do what is needed to use the new certs (including the equivalent of incus cluster update-certificate)?

For servers / member servers:

  1. If an individual server certificate changes, does that require a restart of Incus or any other action (similar to the cluster incus cluster update-certificate command)?
  2. If making use of a new/renewed server certificate requires an Incus restart on that server, what implications are there if that server is a cluster member (particularly on a 3-node setup)?

Haven’t looked into this yet, but is there any command/feature of Incus that copies the client certificates to member servers, when using them for authentication?

I’m also thinking about this in the context of Incus servers also host a LINSTOR storage cluster. (I had asked about a hyperconvered storage / vSAN some time ago, and am in the middle of trying to set it up.) However, the certificate configuration for that looks much more involved and uses Java keystores.

Thanks!