HTTP Validation fail


#1

Hi,
I would like to use let’s encrypt service but i’m dealing a major issue with that,
i’m running a server with 6000 whitelables DNS records pointed to it. so when using their DNS you can reach my server.
i would like to enable ssl for them so that’s shouldn’t be an issue with HTTP validation, i created the validation files and copied them to the right location.
when accessing the validation url i can get the hash that is in the validation files from anywhere in the world.
my server is protected with Incapsula, a reverseproxy and DOS protection.
when trying to initiate the validation let’sencrypt fail to reach my files, I’ve got a feeling that Incapsula recognize Let’sencrypt as a BOT or that it’s doesn’t use a valid USER-AGENT.
i would like to assist you to know how can i white-list Let’sencrypt to make sure it doesn’t get blocked by Incapsula.
any source IP or user-agent that is used can be helpful…
thanks!


Renewal failed after months of success
#2

What is the detailed result you get when you try and verify ( that should give information about what the Let’s Encrypt server saw / got as a response )

The IP address can be any random address (it’s a limited sub=set currently, but in the future could be any.

checking on my servers from the recent hits the useragent was “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)” I don’t know if there are plans to change that though


#3

Hi,
thanks for the quick reply!
here is the error code:
“error”: {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Invalid response from http://domainexample.com/.well-known/acme-challenge/pathtovalidationfile: “\u003chtml\u003e\r\n\u003chead\u003e\r\n\u003cMETA NAME=“robots” CONTENT=“noindex,nofollow”\u003e\r\n\u003cscript\u003e\r\n(function(){function getSessionCookies(){var cookieAr””,
“status”: 403
},


#4

That’s a 403 permission error. If you place a file in .well-known/acme-challenge/test … can you reach it ?


#5

yes, this is what i’m saying.
the file is reachable from everywhere. tried couple of web proxies to validate the URL and it works,everything is reachable from that folder, this is why i have the feeling that Incapsula mark your servers as BAD BOT. I will try to compare the user-agent you gave me with incapsula events…


#6

Let’s Encrypt’s position is that source IP addresses should not be whitelisted because Let’s Encrypt reserves the right to perform validations from undisclosed or completely unpredictable IP addresses (and even hopes to do so in the future) in order to reduce the effectiveness of attacks that involve tampering with network routing between particular portions of the Internet.

So, I would suggest whitelisting by the destination URL path /.well-known/acme-challenge/. It’s very unlikely that bots will gain anything from trying to scrape it because the only thing normally posted there is short-lived random files with unguessable paths (whose content is not very sensitive).


#7

Hi All,

Even we are facing the same issue of http-challenge alone failing.
If we try to access the .well-known/acme-challenge/ from remote , it is working perfectly fine.

The only problem is with the lets encrypt docker with the webroot plugin.

We are getting 404 Error since we have already allowed / whitelisted the URL path in our nginx webserver.
FailedChallenges: Failed authorization procedure. test.manage.iotium.io (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://test.manage.iotium.io/.well-known/acme-challenge/XyLptqPedDc9c03494HyQ-UPIOSr2iAtzhysJKJDBIY: "

404 Not Found

404 Not Found


"

Failed authorization procedure. test.manage.iotium.io (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://test.manage.iotium.io/.well-known/acme-challenge/XyLptqPedDc9c03494HyQ-UPIOSr2iAtzhysJKJDBIY: "

404 Not Found

404 Not Found


"

Another observation is that there is “:” at the end of the challenge url . Is this causing any issues.

Any idea how to resolve this issue.


#8

for me test.manage.iotium.io doesn’t even resolve to an IP address.


#9

I have removed that domain name test.manage.iotium.io


#10

Issue solved,
using Incapsula WAF and DDOS protection does block let’s encrypt HTTP validation check.
FYI to all users trying to get answer from let’s encrypt VIA incapsula Service!!
would recommend moving to a different DDOS protection as Incapsula Service was so bad…
had to discover that manually.
turning all incapsula features off worked.


#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.