Overview:

Because Helm-installed Sensors will initially not be able to update their CAs, the current CA selection logic when issuing new certificates is somewhat broken for them.

The current logic is the following:

• if Sensor supports CA rotation, issue certificates signed by the latest CA
• otherwise issue certificates signed by the primary CA

This does not work well in some cases.
E.g. Helm-based Secured Cluster uses CA1, connects to Central that uses CA2 as primary, a cert refresh request will return leaf certs based on CA2 - breaks the Secured Cluster (more specifically admission-controller), even though it could work for as long as CA1 is still valid.

Proposed solution:
Update the cert refresh API to allow Sensor to send a fingerprint of its own CA.
Central then has the following logic:

• if Sensor supports CA rotation (advertised via sensor capability), use newer CA to issue certs
• otherwise, if Sensor sent CA hash, prefer the CA that Sensor knows
• otherwise, fallback to primary CA

Acceptance Criteria:

A list of specific needs or objectives that this task must deliver in order to be considered complete. Complete during Refinement status.