For reference: External Account Bindings require three fields on an ACME Issuer which represents your ACME account. These fields are; the keyID of which your external account binding is indexed by the external account manager, keySecretRef which references a secret containing a base 64 encoded URL string of your external account symmetric MAC key, and finally keyAlgorithm , the MAC algorithm used to sign the JSON web string containing your External Account Binding when registering the account with the ACME server.
I have my account id, but I do not know the MAC key, or its algorithm.
Cert-manager version is 1.16.
Let’s Encrypt does not use External Account Bindings.
Some CAs do, like Sectigo, and those EAB credentials are available from the CA’s web interface. This allows you to have multiple independent ACME accounts that are all associated with a single external account/identity.
If you want to use the same Let’s Encrypt account on multiple machines, the only credential you need to copy is the account key.
Looking at cert-manager, it seems like all you have to do is ensure that the issuer’s privateKeySecretRef points to the same private key on all clusters. Looking at https://github.com/jetstack/cert-manager/issues/2990, it looks like doing that (sharing the secret between clusters) might not be possible today.
Thanks for the fast reply, I have the ability to create an identical Secret across multiple clusters, and will give that approach a try by providing privateKeySecretRef explicitly.
In ACME, the account ID is usually automatically discovered using the account private key. So usually all you have to do is feed the right private key in to your client.
Based on munnerz response on the issue tracker, I am suspecting that it’s not possible to provide an existing private key to cert-manager.
You could try asking in that issue or in their Slack channel.