Certificate secrets are not recreated when critical fields change

[stephenc]

Describe the bug:

1. If a certificate is configured with a secretTemplate, changes to the secretTemplate are not reflected until the certificate is renewed.
2. If a certificate is configured to create a JKS keystore, changes to the JKS password are not reflected until the certificate is renewed.
3. Adding keystore configurations do not get reflected until the certificate is renewed

Expected behaviour:

• changing the secretTemplate should trigger an update of the secret. given that the secretTemplate can only contain annotations and labels, it should be possible to just update the annotations and labels on the secret without renewing the issued certificates in the secret
• adding a keystore configuration should refresh the secret with the keystore configuration as the information required to populate the keystore should already be present in the secret
• changing the JKS password should trigger a refresh of the keystores that were encrypted with the password, otherwise the keystores cannot be used. Again it should be possible to update these stores without renewing the issued certificates as they just present a convenience reformatting of the information contained in the other secret entries.

Steps to reproduce the bug:

1. Create a Certificate resource.

2. Once the certificate secret has been provisioned, edit the Certificate to include a secretTemplate in the spec

3. Observe that the secret is not updated to include the annotations/labels in the secretTemplate

4. Add a keystore configuration to the certificate (will probably require creation of a separate secret to hold the keystore password)

5. Observe that the secret is not updated to include the keystore

6. Renew the certificate, observe that the keystore and annotations/labels are now present in the secret

7. Change the secret containing the keystore password to use a different password

8. Observe that the secret is not updated with a keystore using the new password

9. For a JKS keystore, observer that the truststore.jks is now rendered invalid as keytool cannot read it

10. Renew the certificate, observe that the keystore is now correctly encrypted.
    Anything else we need to know?:

Environment details::

• Kubernetes version:
• Cloud-provider/provisioner:
• cert-manager version:
• Install method: e.g. helm/static manifests

/kind bug

[cert-manager-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale