Making ACME Issuer privateKeySecretRef optional

[devdattakulkarni]

Currently the Issuer/ClusterIssuer Custom Resource Spec contains 'privateKeySecretRef' attribute. The controller internally creates a Secret with the name specified in this attribute's value. Is this secret supposed to be used by users anywhere/anytime? If not, can this field be removed? The controller can internally create a Secret using some random name.

The Issuer/ClusterIssuer Specs have several attributes. By removing privateKeySecretRef if it is not used, configuring and using the Custom Resource will become simpler.

[munnerz]

This private key is used to store the ACME/Let's Encrypt account private key, not the private key used for any Certificate resources. The account private key identifies your company/you as a user of the ACME service, and is used to sign all requests/communication with the ACME server to validate your identity.

We could look at allowing this field to be omitted altogether and auto-generating the name. I see two options:

• Generate a random name - this will mean we need to record the actual generated name somewhere, or label the secret in order to identify/discover it later
• Use the name of the issuer (optionally with some prefix/suffix) - this will skip the need to generate and store a random name, but it could lead to someone getting confusing misconfigurations if they have a Secret with the same name as an Issuer already in a namespace.

On the other hand, making the fact that an account private key exists obvious to users can be seen as beneficial as it illustrates to users that they do have an identity with the ACME server, and that it can be transferred between clusters. Although perhaps this is a more advanced use-case that is necessary to expose on the 'quick start' path 😄

/area api
/area acme
/kind feature
/priority awaiting-more-evidence

[adi658]

I donno if its relevent here but is there a way you use existing secret?
I have a key/cert from a 3rd party CA which is valid. And I want to setup a 3rd party issuer which using this particular key/cert in the secret.

I tried putting the key/cert in the issuer secret and ingress controller secret, but it doesnt take it.

[retest-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.
Send feedback to jetstack.
/lifecycle stale

[retest-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

[munnerz]

I don't think this is really something we are looking to support in the near future. Given users don't need to define a issuer resources particularly often, I think the burden of requiring a user name a Secret resource to contain the credentials, and thus acknowledge that the credentials exist, is much burden.

[samos123]

I as a new user was very confused about privateKeySecretRef because I first assumed that I had to populate this secret myself. I think from UX perspective since the user doesn't need to care about it, it should be removed from the required config and be optional.

[sayotte]

I appreciate that the current, mandatory status of this parameter forced me to learn that I have a crypto identity with my ACME provider, because I do constantly destroy and rebuild k8s clusters to make sure my process is consistent. Based on my new understanding, it sounds like I could discard this identity every time I rebuild and still produce new certs for my domain, but I'd lose my ability to revoke older certs from previous incarnations of my cluster. Maybe no big deal, but if I had a use-case where it was important I'd be upset to learn I'd made a mistake after-the-fact.

That said, it took some digging for me to understand this. A lot would have been saved if the doc-comments in the example configs at https://cert-manager.io/docs/configuration/acme/ were just made a bit richer. Perhaps some wording like?:

# Secret resource that will be used to store the account's private key.
# This is your identity with your ACME provider. If you lose this
# identity/secret, you will be able to generate a new one and generate
# certificates for any/all domains managed using your previous account,
# but you will be unable to revoke any certificates generated using that
# previous account.

[AlverezYari]

I've been fighting this all day, these docs certainly need to be cleaned up there is a bunch of 'yada yada' type shortcuts in them and it makes for a long day trying to Google-fu past their poor docs.

[iamantil]

Hello Everyone,

I have an issuer with the name "aeg-eab" and the privateKeySecretRef as name: "aeg-secret". Which is said in the official docs.
But when applying the issuer.yml file the state of the issuer remains "false". Although I am passing the "preferredChain: root cert" in the issuer.yml.

Is there anything that I am missing with.
Guidance would be greatly appreciated.

Thanks