Hi again @byte,
I went through the request logs from your client during the period of 13/11/19 14:38 UTC to ~14:45 UTC and I believe you have a bug in your ACME client code that is causing it to act out of protocol.
Here’s an annotated breakdown of the requests I saw and the relevant resource URLs. Since POST-as-GET is not yet mandatory we can all access them in our browsers to see first-hand what the final result of each resource is.
13/11/19 14:38:14 - client POSTs new-order, w/ 2 idents (srv162011.hoster-test.ru and www.srv162011.hoster-test.ru). This created the order: https://acme-v02.api.letsencrypt.org/acme/order/71547863/1503782190 We’ll call the authz for srv162011.hoster-test.ru “authzA” and the authz for www.srv162011.hoster-test.ru “authzB”.
13/11/19 14:38:14 - client GETs authzA (https://acme-v02.api.letsencrypt.org/acme/authz-v3/1221077576), it’s pending as expected since no challenge has been fulfilled.
13/11/19 14:38:14 - client GETs authzB (https://acme-v02.api.letsencrypt.org/acme/authz-v3/1221077577), ditto here RE: pending status.
13/11/19 14:40:08 - client GETs authzA’s HTTP-01 challenge
13/11/19 14:40:09 - client POSTs authzA’s HTTP-01 challenge, initiating the challenge.
… client GET polls the challenge for a bit while it still reports status pending …
13/11/19 14:40:13 - client GETs authzA’s HTTP-01 challenge, status is now valid, the HTTP-01 auth of srv162011.hoster-test.ru suceeded.
13/11/19 14:40:13 - client GETs authzB’s HTTP-01 challenge, it is pending because the challenge hasn’t been initiated.
13/11/19 14:40:14 - client POSTs authzB’s, HTTP-01 challenge, initiating the challenge.
… client GET polls the challenge until 14:40:20 while it still reports status pending, but then seems to give up …
13/11/19 14:40:47 - challenge is marked invalid server-side because www.srv162011.hoster-test.ru failed the HTTP-01 challenge.
13/11/19 14:45:24 - client now GET’s authzA’s DNS-01 challenge. It’s reported pending but the overall authz is already valid because of the HTTP-01 challenge.
13/11/19 14:45:25 - client POST’s authzA’s DNS-01 challenge. This is a no-op because the associated authorization is already valid.
… client GET polls the challenge for a bit, it never changes from pending for the reasons listed above …
13/11/19 14:45:30 - client GET’s authzB’s, DNS-01 challenge. Its returned with invalid status because the associated authz is invalid because of the failed HTTP-01 challenge attempt.
The main take away’s from the above is that your client first tried HTTP-01 first, passed one and failed the other. At this point you need to create a new order if you want to change to using DNS-01 authentication. Overall it looks like the client code is polling at the most fine-grained resource (challenges) instead of a higher level (order, or authorization) and I suspect changing the code to operate that way will work better.
One aspect of note to me is that the DNS-01 and TLS-ALPN-01 challenges in the authorization that was made valid by the HTTP-01 challenge are being reported “pending”. I think that might be a regression on our side. I would have expected these two unused challenges to be returned with status invalid. I’ll look into this more and bring it up with my colleagues. Edit: see follow-up comment, we’ll soon not be returning the other challenges in a valid/invalid authz
Hope this helps explain the situation. Good luck!