To validate a DNS challenge, the server performs the following steps: 1. Compute the SHA-256 digest [FIPS180-4] of the stored key authorization 2. Query for TXT records for the validation domain name 3. Verify that the contents of one of the TXT records match the digest value If all of the above verifications succeed, then the validation is successful. If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".
But status not stay to "invalid" it is just "pending" again and again.
No error or somthing else.
What i do wrong?
I 100% know: i set valid DNS to domain. I do it to another 90+ domains in automatic mode.
And i valid "www.domain", but can't valid domain without "www".
Read manual it is not answer. In manual i read - server return valid or invalid result.
I can't get valid or invalid, i get just "pending".
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
Update here: I found we do have code in place to be removing the unused challenges in a valid/invalid authorization (e.g. rather than reporting them pending forever). I thought we had deployed this code but it looks like we delayed the roll-out at the time it was implemented and it wasn't picked up again. We'll get this fixed shortly and that should help avoid the potential for this confusion to occur.
@byte Thanks for posting about this in the forum We might not have noticed this missed roll-out as quickly otherwise.
This change was deployed to our staging environment yesterday. I've verified today that when I fail an authorization only the challenge with the invalid status/error is returned. The same should occur with one valid challenge in an authorization. We'll likely promote this behaviour to production next week.
We might not have noticed this missed roll-out as quickly otherwise.