> > 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?
>
> Only 1 private key account is created by section, so the ACME server
will find
> the account related to this key and reuse it for every certificates.
Ah, sorry, I was confused because there are multiple crt-bases,
acme section follows the one that is specified in the global config, my bad.
I'm not sure about crt-base. At least introducing an option just for EAB
doesn't seems to make that much sense, I will remove that base handling
for now.
> > 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.
> >
>
> I'm wondering if this is a good idea to rely on a file for this. It's
only 2
> shorts strings, doesn't it make sense to put that directly in the
> configuration? I fear it complexifies the file handling without much
benefits.
The reason I put them into files is because they are credentials. The
fact that
they are short or not doesn't matter. They are similar to username and
password.
So in my opinion storing a key in the config file shouldn't be allowed,
as it is a footgun. I've seen a few people putting that on github in public.
It isn't as obvious that that short base64url encoded string is a
credential.
What exactly can the attacker do will depend on the ACME provider,
but it is a similar threat to the account key theft, may be worse or may
be not.
Some other clients allow to put them in the config, but at least those that
are servers allow to load from the file.
Nginx, Caddy, Stalwart do, out of the major ones.
In some cases like in Stalwart you can even specify PEM files inline.
Caddy and Stalwart have interpolations to load from env or file.
Nginx does weird thing where id is specified in the config, but key
is in the separate file or inline in the config, that is just weird.
I think if I made them literal options in haproxy, then:
1. would replace files usage with env vars basically.
2. would introduce a footgun because of lack of strong permission
separation.
It is not like that is completely unworkable, you can split a single
config file into two after all, and make one part have different
permissions.
Some users may also have a different security model for the config file.
Using env vars is also common for this, but I'm not sure, files work better?
I'm ok with env variables but not ok with literal values.
For usecase of using systemd-credentials it better be a file path.
HAProxy doesn't have "embed file as inline str" thing, without that
preprocessor
directive there is a big incentive to specify creds directly in the config.
For a basic automation writing fields from a json file into files is simple,
simpler than templating a config.
Though for that case there are also other ways automatian could be done
it is possible to register an account using Lego and then pass it to
haproxy,
that should work and doesn't require haproxy to support EAB.
Some setups have a haproxy config that is immutable, and world readable,
like nixos setups.
Literal values could be handled in addition to the file paths, but that adds
even more complexity.
Overall I just don't think it is a great idea.
I would much much prefer if creds were a single file though, fiddling with
two files isn't great, but inventing own file format for that also isn't
great.
File config does indeed add some complexity, it is true, I don't like that.
So yeah, that was an intentional design choice, has downsides though,
I hope I made benefits clear too.
> > Do you prefer if I submit next patch as a reply to this thread or as a
> > completely new mail, or don't care?
>
> You can rebase directly from master, then send your series again with a
> git-send-email -v2 --in-reply-to=... with the latest email ID of the
current
> thread.
Ok, good, thanks!
