I’m working on an application that needs to try HTTP-based authz first; then, if that fails, it’ll try DNS-based authz. (This would be after having locally confirmed that HTTP-based authz should work; the problem is that there are cases where local HTTP authz passes but a remote HTTP authz check still fails.)
What I’m seeing (against the v2 API), though, is that once the HTTP authz fails, the request to accept the DNS challenge fails because “Unable to update challenge :: authorization must be pending”.
I don’t see anything in RFC 8555 concerning switching challenge methods after one fails; there’s a section on retrying a challenge, but it doesn’t seem to envision (or to proscribe) trying a different challenge method after one has already failed.
One way around this would be to create a new certificate order just to get a new authz. But that seems pretty inefficient; I’m hoping there’s a way to reuse the existing authz (and order).