HTTP-01 invalid status Error 400

Hello, I am failing to obtain a SSL Cert from let's encrypt.
DNS seems to be fine, I see that certbot --nginx tries to rewrite the configuration for nginx with a new location for .well-known\acme-challenge but seems to fail with 400 not found. Port 80 is open.

My domain is:

I ran this command:
certbot certonly --dry-run

It produced this output:
How would you like to authenticate with the ACME CA?

1: Nginx Web Server plugin (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel):
Simulating a certificate request for

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Type: connection
Detail: Fetching Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):
Nginx 1.20.1

The operating system my web server runs on is (include version):
RHEL 7.9

I can login to a root shell on my machine (yes or no, or I don't know):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Certbot 1.18.0

I don't know where you read that, but I'm clearly reading a "Timeout during connect" and not a "file not found" error.

I'm afraid the whole IP address is unresponsive: not just port 80 isn't working, but I can't ping it, nor are other common ports such as 443, 21, 22, 110, 143 et cetera unresponsive. Not even a "closed" port, no, just time outs.

1 Like

Presuming HTTP can reach your server, and if the problem persists, you might want to try using the
--webroot authenticator instead.

If HTTP can't reach your server, you can still try using DNS-01 authentication.
But the end-game is automation, so be sure to go down a path that ends with that.

That statement needs clarification:

  • Did the open it only to specific source IPs?
  • Did they open it only from specific user agents?
  • Did they open it only for the expected challenge path ("/.well-known/acme-challenge/")?

Is that a response to any of the three questions I posed?
If not, and it is just the outbound allowed access, then I can see why the certificate requests are failing.

you are probably right. is there an indirect method of obtaining a SSL certificate from Let's encrypt?
for example with globalsign you provide a CSR and you receive a CRT.

security won't open the port to outside until I install a certificate, I installed a self-signed certificate. will see if that's enough.

They should open HTTP first; So you can get a cert.
Then open HTTPS once you've installed the certificate.
That said, yes, LE can work with a self-signed cert.
BUT, the first request will always go to HTTP, and must reach some system.
HTTP challenge requests can then be redirected to HTTPS, but whatever for?

If it is enough for them to open HTTP, then it is progress.
Without an open HTTP path, there is only DNS-01 authentication left.

Providing a CSR would not alleviate the obligation of Let's Encrypt to validate your hostnames, so you end up with the same problem again. Please read how Let's Encrypt works on:

1 Like

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