lego icon indicating copy to clipboard operation
lego copied to clipboard

Allow passing account credential information via CLI arg/Envvar

Open jhg03a opened this issue 3 years ago • 4 comments

  • [x] Yes, I've searched similar issues on GitHub and didn't find any.

Detailed Description

If you're using a single account spread across many machines using external account binding, having the account info and key present on disk is less than desirable. Instead, I'd prefer to see it as a CLI arg or environment variable so that I can obtain the information as needed from whatever secret store I might be using and never write it out to disk.

jhg03a avatar Mar 16 '21 15:03 jhg03a

Hello, the EAB information are provided via CLI flags:

   --eab                        Use External Account Binding for account registration. Requires --kid and --hmac.
   --kid value                  Key identifier from External CA. Used for External Account Binding.
   --hmac value                 MAC key from External CA. Should be in Base64 URL Encoding without padding format. Used for External Account Binding.

https://go-acme.github.io/lego/usage/cli/

I'm not sure to understand your problem :thinking:

ldez avatar Mar 16 '21 17:03 ldez

The hmac/kid is used to register the account with the signing authority. It's not a replacement for the account key generated, and it's only good once.

jhg03a avatar Mar 17 '21 16:03 jhg03a

The EAB information is defined by the RFC and nothing else, each ACME provider can create an API to generate the EAB information. There is no common way to handle that because it's not in the ACME RFC.

I'm still not sure to understand your issue.

ldez avatar Mar 18 '21 01:03 ldez

When using sectigo with eab, the hmac/kid are only ever used once to authorize the first request and setup the account info normally stored in .lego/accounts/acme.sectigo.com/<email>/. After that first usage, you still have to supply the kid/hmac args, but it doesn't matter what they are. It recognizes that the account key used in that first request is simply authorized and can bypass any challenge mechanism for requests included in the sectigo account scope. If you try to reuse that same kid/hmac on a different machine without the account info already setup, it will fail because only one account is permitted per kid/hmac. So that means you have to ship around to all systems using sectigo the contents of the .lego/accounts/* directory.

The request is so that instead of having to explicitly setup that directory, you can simply pass the contents of the account.json file and account key so that they never have to exist on disk. This is relevant when you have a secret-as-a-service solution to track usage of and access to that privileged information.

jhg03a avatar Mar 18 '21 16:03 jhg03a