Currently, if a user sets up kube-lego to point at the staging environment, and later updates it to point to production (or any other acme URL), the user is presented with a cryptic (for users unfamiliar with the ACME protocol) error messages when requesting certificates:
error while authorizing: getting authorization failed: 403 urn:acme:error:unauthorized: No registration exists matching provided key” context=acme domain=xxx.yyy.zzz
This comes about because kube-lego attempts to use the already-generated account for the old URL with the new URL, consequently causing an error.
We should generate a new name for the secret on a per-URL basis - this could be achieved through the use of an annotation or label that indicates the ACME URL that the secret is valid for.
Currently, if a user sets up kube-lego to point at the staging environment, and later updates it to point to production (or any other acme URL), the user is presented with a cryptic (for users unfamiliar with the ACME protocol) error messages when requesting certificates:
error while authorizing: getting authorization failed: 403 urn:acme:error:unauthorized: No registration exists matching provided key” context=acme domain=xxx.yyy.zzz
This comes about because kube-lego attempts to use the already-generated account for the old URL with the new URL, consequently causing an error.
We should generate a new name for the secret on a per-URL basis - this could be achieved through the use of an annotation or label that indicates the ACME URL that the secret is valid for.