Add --no-solver flag for pre-authorized domains (EAB with out-of-band DCV)

[lwillek]

Welcome

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

How do you use lego?

Binary

Effective version of lego

4.32.0

Detailed Description

Some ACME servers (enterprise/private CAs, managed PKI platforms) pre-authorize domains out-of-band and return authorizations as already valid — no challenge solving needed. RFC 8555 §7.4.1 explicitly permits this. lego currently requires a solver, fails with No challenge selected if not.

Proposal is to add a --no-solver flag, to handle that case cleanly.

The needed changes are imho small, I am going to create a PR for it.

[ldez]

Before working on this, I want you to read the PR template:

lego/.github/PULL_REQUEST_TEMPLATE.md

Lines 3 to 7 in 87b172f

	IMPORTANT:
	1. Create an issue and wait for a maintainer to approve it BEFORE opening a pull request.
	2. Don't open a work-in-progress pull request. If you open a PR, the PR must be ready to be reviewed.
	3. If a pull request doesn't follow one of the previous elements, it will be closed.

For now, I will take no decision on this because I'm focused on the v5

Note for myself: this cannot be tested because pebble doesn't support it.

https://github.com/letsencrypt/pebble/blob/e4c1c32d485df3b436e6d0039bfa2e3318c4ccb9/README.md?plain=1#L57-L58

[ldez]

Duplicate of #2017

[lwillek]

Dang, I missed #2017 - thanks for linking! Yes, this one here is a 100% duplicate.

Yes, I saw the pinned comment - current focus is on v5 - to me this issue is not urgent - only annoying (I explained why in #2917)

In case someone searches for the same and lands here, there is a "workaround" available for such cases. This technically works fine, as the http challenge is not even checked in case of ACME-EAB with out-of-band DCV. The only issue with that is that it confuses people a lot,

lego \
  --server "$ACME_URL" \
  --email "$ACME_EMAIL_ADDRESS" \
  --accept-tos \
  --eab --kid "$ACME_KEY_ID" \
  --hmac "$ACME_KEY" \
  --domains example.com \
  --http \
  --http.port localhost:54321 \
  run

[ldez]

I answered quickly to your issue with an incentive to read the PR template.
I think I expressed a clear status: the proposal is neither accepted nor rejected, so not approved.

You didn't read my message, and opened a PR without reading the PR template.

Maybe there have been some misunderstandings, so I don't take it badly, but avoid doing that: please read PR template and comments.

In all cases, even if I had approved the proposal, your implementation is a bit too naive, and the flag name not so right.

I understand the need, and it could be in a part of the v5.
When the time will come I will create an implementation and ask you to test it if you agree.

[lwillek]

No bad feelings, especially when the implementation is too naive, or flag names do not fit - it was meant as proposal. I didn't mean to bother you with the PR; I wanted to fix a pain-in-the-neck situation for me, and sometimes a few lines of code are just easier than words.

Indeed, I was not reading your earlier comment here - exactly overlapping with PR creation, sorry for that.

In case it makes it to v5 - I am more than happy to test!