HTTP status invalid even after HTTP challenge is valid

[gowebsmarty]

Hello Youri,

We are very thankful for your work. I see that some of the authorizations are still invalid even after HTTP challenge is valid. Can you check if there is anything wrong in updating of authorizations after the HTTP challenge is passed.

` [{\"type\":\"http-01\",\"identifier\":\"xxxxxx.ml\",\"filename\":\"iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s\",\"content\":\"iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s.Ls2L06CdQ5fV1hLv4r5DIVmk-x-DzO_qUMOUhCuGRME\"}] Creating HTTP challenge file http://xxxxxx.ml/.well-known/acme-challenge/iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s [30-01-2020 09:51:32] : HTTP challenge for \'xxxxxx.ml\' valid.

[{\"authorizationURL\":\"https:\/\/acme-v02.api.letsencrypt.org\/acme\/authz-v3\/2548741019\",\"identifier\":{\"type\":\"dns\",\"value\":\"xxxxxx.ml\"},\"status\":\"invalid\",\"expires\":\"2020-02-06T09:51:34Z\",\"challenges\":[{\"type\":\"http-01\",\"status\":\"invalid\",\"error\":{\"type\":\"urn:ietf:params:acme:error:unauthorized\",\"detail\":\"Invalid response from http:\/\/xxxxxx.ml\/.well-known\/acme-challenge\/iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s [185.27.134.201]: \\"function toNumbers(d){var e=[];d.replace(\/(..)\/g,func\\"\",\"status\":403},\"url\":\"https:\/\/acme-v02.api.letsencrypt.org\/acme\/chall-v3\/2548741019\/NtejgQ\",\"token\":\"iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s\",\"validationRecord\":[{\"url\":\"http:\/\/xxxxxx.ml\/.well-known\/acme-challenge\/iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s\",\"hostname\":\"xxxxxx.ml\",\"port\":\"80\",\"addressesResolved\":[\"185.27.134.201\"],\"addressUsed\":\"185.27.134.201\"}]}]}] `

[yourivw]

Hi, this looks like a problem that exists on your server. By the response and the kind of domain name, I'm guessing you're using a free webserver? This webserver seems to add javascript code to show ads, which causes corrupted content of this authorization file when requested by LetsEncrypt. You can see the authorization request received JS code, highlighted in bold:

[{"authorizationURL":"https:\/\/acme-v02.api.letsencrypt.org\/acme\/authz-v3\/2548741019","identifier":{"type":"dns","value":"xxxxxx.ml"},"status":"invalid","expires":"2020-02-06T09:51:34Z","challenges":[{"type":"http-01","status":"invalid","error":{"type":"urn:ietf:params:acme:error:unauthorized","detail":"Invalid response from http:\/\/xxxxxx.ml\/.well-known\/acme-challenge\/iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s [185.27.134.201]: \"function toNumbers(d){var e=[];d.replace(\/(..)\/g,func\"","status":403},"url":"https:\/\/acme-v02.api.letsencrypt.org\/acme\/chall-v3\/2548741019\/NtejgQ","token":"iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s","validationRecord":[{"url":"http:\/\/xxxxxx.ml\/.well-known\/acme-challenge\/iWHOlmQ_z7HspdKqmsdflrSI42Fb2U0-WoL26CFKw2s","hostname":"xxxxxx.ml","port":"80","addressesResolved":["185.27.134.201"],"addressUsed":"185.27.134.201"}]}]}]

I don't think you will be able to prevent this on such a webserver, except by using DNS authorizations.

[gowebsmarty]

Hi,

Thanks for the quick response. I have just masked the domain name with xxxxxx. Its a domain name with Linux hosting and Apache server.

As per my above example code, the local check says HTTP challenge is valid but http challenge verify from acme have returned invalid response. Any ideas on how this response is different compared to local check? Anyhow, this is one of the rare case and not really a common issue.

[yourivw]

Well like I said, a JS script is being loaded by either the webhosting or maybe the domain supplier. I'm guessing it's the domain supplier, but I cannot check that now your website is not reachable anymore. However, I have seen that before on such domains.

The reason that the local check is valid is probably because it doesn't load the script when the server is requesting a page from itself, but it does load advertisement scripts for remote users/requests. I don't think you will be able to work around this using either this webhosting or this domain.

FYI: you have masked the domain name in this issue, but it's still visible in the linked LetsEncrypt authorization URL anyway.

[gowebsmarty]

@yourivw That makes sense!. Thank you :)