> You should probably split this commit in two, introduce the HMAC in
the jws
> first, then use it in the ACME code.
Sure. Also makes sense to jws_b64_protected() into a separate commit
from jws_b64_hmac_signature() maybe, as they are unrelated.
> I don't know if that's a good idea to use crt-base here, if it's not
a PEM
> certificate we will probably need something else to configure the
path. Like an
> acme-account-path or something like that.
Yeah, it is not PEM, also, because it isn't PEM .key extension may be
confusing,
I should probably change the preferred extension.
And by that logic it shouldn't be related to the crt-store. I'm not sure.
At the same time I think it makes some sense for them to be in the same
location
as the account-key, they are the account credentials.
Now that I think about it, current behavior seems strange, what if I
refer to
the same acme section within multiple crt-store sections? Will that make
multiple accounts currently?
For a name "acme-base" would make the most sense in my opinion,
similar to ca-base, key-base, crt-base.
acme-base or acme-account-base can be an option on the acme section,
or maybe global section, and it will specify acme account related paths
for it.
So example.com.pem will be relative to crt-store, but pebble.account.key and
eab credentials will be relative to the acme-base.
What do you think? That is a breaking change.
Do you have any thoughts with regards to EAB creds implicit file loading
behavior?
I think I will remove it, it makes thinks more confusing, and probably
add a warning when file isn't found or empty.
I want to have some option to remove credential without changing haproxy
config.
Maybe also what would make sense is to allow only empty files, but they
should
still exist, so that use case will be covered,
or can make the parsing being just in time, though I don't like it that
much.
Do you prefer if I submit next patch as a reply to this thread or as a
completely new mail, or don't care?
