Problem finding dns-persist-01 in staging

[sebastiannielsen]

That would require explicit support. Once the pull request is approved, it will only be able to use the "main" accounturi, unless the Net::ACME2::Challenge object exposes "unknown" variables from the JSON structure.

[felixf]

@rmbolger

Be wary against testing too closely to Staging's implementation right now though. It's still using the draft-00 spec which doesn't include accounturi in the challenge object like draft-01 does. Anyone know if Pebble has updated for draft-01?

Pebble hasn't been updated yet, but I created a PR a few days ago to return accounturi when I noticed it was missing: Add accounturi to dns-persist-01 challenges by felixfontein · Pull Request #544 · letsencrypt/pebble · GitHub

[MikeMcQ]

@rmbolger

The user should have a choice whether to use the real account URI or whatever is presented in the challenge. And the default should probably be to use what is presented in the challenge.

Agree on having a choice. Don't agree the Challenge URI is best default.

When different, any "blind" choice is going to be wrong for some people. And, perhaps even for important reasons. For example, the draft RFC in 7.2 says:

Domain owners and auditors who require independent verifiability SHOULD use the ACME account URL directly, since third parties cannot independently determine which account is bound to an alternative URI.

What to do when they differ seems use-case and CA dependent.

It will be interesting to see how LE plans to set and allow control of the Challenge accounturi. I'm assuming, at least for the start, that it will just be equal to the main accounturi to avoid the mapping that can otherwise be done with different ACME Accounts. But, that is purely a guess.

[sebastiannielsen]

@aarongable

Correct (although LE has no intention of implementing that).

I have a suggestion to enable this, but to prevent breakage, allow people to out out of it with "nojit"

For example:
profile => "shortlived,nojit"
or
profile => "tlsserver,nojit"
or
profile => "nojit"

This would allow incompatible clients (for example, the ACME client in synology boxes) to support dns-persist-01 validation without any change at all, it would just try to validate for example HTTP-01, fail that validation, but since theres a valid DNS-PERSIST-01 validation in the back, it would "silently accept" that and allow the client to work.

[rmbolger]

@MikeMcQ

And, if the CA Server uses the Just-In-Time Validation optimization (draft1 4.4) the Client will never see the Challenge object anyway. Right?

@aarongable

Correct (although LE has no intention of implementing that).

It sounds like LE won't be implementing JIT validation. So clients won't be able to use it unless they explicitly support dns-persist-01.

I'm curious who will implement it (if anyone) though.

[orangepizza]

Dose pebble with alwaysvalid=1 act differently from successful jit validation?

edit: id'd different becaues it still need to post at challenge to start validation task: