Unable to update challenge authorization must be pending - status 400

Help
1

I have been using LE for about 2 years now and no problems at all. About 2 months ago I started getting this error when certificates try to update. "Unable to update challenge authorization must be pending - status 400".

I am an IT guy or 32 years, I checked everything, and nothing has changed on my end other then updates, same server, Sonicwall, cabling all is the same. I even had my service provider here twice and they "COX" cant find any issues. DNS is done at GoDaddy and all is fine, like I said nothing has changed. websites work fine, ports 80 and 443 are open and working fine. I just cant figure out why the certificates are having issues updating.

When I run the Letsdebug, I get 3 different error messages and then the 4th time it says all is OK. Its driving me crazy as I just cant figure out what's going on. Any ideas?

LE 1
LE 11290×906 142 KB

2

LE 2
LE 21278×685 102 KB

3

LE 3
LE 31273×558 74.9 KB

4

LE 4
LE 41326×576 61.3 KB

sorry for the 4 reply's but it would only let me do one image at a time.

1 Like
5

Hi @Johnnyz, welcome to the LE community forum :slight_smile:

Has there been any update to the FW?
Are there any entries in the logs dropping HTTP?

6

Thanks for the reply,

No firmware updates to the SonicWALL that I did. But it is set to auto update so it could have updated firmware, but I have never had any problems with SonicWall updates in the past years.

I still think something with the internet, but I have been working with COX for 2 months and they say all is fine. I escalated the ticket all the way up to the top tear and they say all is fine, so Like I said I don't have any more ideas.

I just looked and the SonicWall TZ400 is up-to-date on firmware 6.5.4.8-89n.

Not sure if there is some test I can set to run to see about internet timeouts?

7

There are plenty of sites out there that can check your site to see if it is reachable or not.
Some will only ping it, but some can do HTTP GETs.

Also, I would look at the active concurrent connections through the firewall.
Graph that over time and see if it ever hits some upper limit.
And also on the web server as well.

8

Network Sicurity Alpiance (SonicWALL)
Connections: Peak:471 Current:90 Max:93750
Connection Usage: 0.083%

Really not sure why I have 90 connections, no one is on my sites?

9

To me, a 471 peak is really of no concern.
So I think that (DoS) is not part of the problem.

10

I do now notice that the HTTP challenge requests are being redirected to HTTPS (needlessly).
Maybe we can modify the nginx config to allow that.
Let's Debug (letsdebug.net)

curl -Iki http://artisticimages.com/.well-known/acme-challenge/Test-File-1234

HTTP/1.1 301 Moved Permanently
Location: https://artisticimages.com/.well-known/acme-challenge/Test-File-1234
11

I use Hestia as my web server, I have been on the forums with them, there great. They say it has nothing to do with anything on Hestia as no one else using Hestia is having this issue? Don't know?

12

ya, I can run letsdebug 4 times and get 3 different messages, and then it will say all is good?

13

Can we see the nginx config?

14

nginx.conf.txt (6.5 KB)

15

None of the included files were included.
Try showing the output of:
sudo nginx -T

16

nginx.conf.txt (38.2 KB)

17

I would remove these lines from all files:

include /home/admin/conf/web/artisticimages.com/nginx.conf_*;
include /home/admin/conf/web/artisticimages.com/nginx.ssl.conf_*;

And replace this line:
return 301 https://$host$request_uri;
in this file:
/home/admin/conf/web/artisticimages.com/nginx.forcessl.conf
with these lines:

  location ^/(?!\.well-known) {            # skip challenge requests
    return 301 https://$host$request_uri;  # send all requests to HTTPS
  }# location

Then include a root within the file
/etc/nginx/conf.d/domains/artisticimages.com.conf
add a line in this format (for a path of your chosing):
root /new/dedicated/challenge/path; # path for challenge requests

18

so this is for artisticimages. but I have other websites, and I get this error on all websites, so how do I fix this globally?

19

Apply that last paragraph to all your vhost config files.

OR
You could use the same path for all files by including that root line within the global include.

20

and FYI, I did a fresh setup, new server, new install of Debian 11, Hestia, everything and got the same issues, so is this an issues with the nginx config in Hestia?