When using a chained store of Kubernetes -> Memory -> File, a file-backed cert with a valid ResourceVersion could not be updated when the Kubernetes store was offline, as the Memory store was skipping the update if the ResourceVersion was not changed.
The Kubernetes store passes through the secret update without a modified ResourceVersion if the Secret controller is not yet available to round-trip the secret through the apiserver, as the apiserver is what handles updating the ResourceVersion when the Secret changes.
In RKE2, this caused a deadlock on startup when the certificate is expired, as the apiserver cannot be started until the cert is updated, but the cert cannot be updated until the apiserver is up.
Fix this by also considering the certificate hash annotation when deciding if the update can be skipped.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
(cherry picked from commit 242c2af2db)
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Fixes an issue where an expired Kubernetes secret would replace the renewed locally-cached cert after cluster startup.
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
Refreshing the cert should force renewal as opposed to returning
early if the SANs aren't changing. This is currently breaking refresh
of expired certs as per:
https://github.com/rancher/k3s/issues/1621#issuecomment-669464318
Signed-off-by: Brad Davidson <brad.davidson@rancher.com>
