HTTP-01 validation fails with connection reset, although domain is publicly reachable

Help
1

I am having an issue with HTTP-01 validation for:

elsednice.skgo.org

The DNS A record points to:

217.169.210.135

The HTTP-01 challenge file is publicly accessible over IPv4. I have verified it from an external curl service and it returns:

HTTP/1.1 200 OK

with the exact challenge response requested by Certbot.

For example, the current challenge URL returns the correct token successfully from an external location.

I also ran tcpdump directly on the web server during Let's Encrypt validation.

The validation attempt from 66.133.109.36 shows:

66.133.109.36.59615 > 192.168.40.138.80: Flags [S]
192.168.40.138.80 > 66.133.109.36.59615: Flags [S.]
66.133.109.36.59615 > 192.168.40.138.80: Flags [.]
66.133.109.36.59615 > 192.168.40.138.80: Flags [R.]

There is no HTTP GET request following the TCP handshake.

Certbot reports:

Challenge failed for domain elsednice.skgo.org
Type: connection
Detail: 217.169.210.135: Fetching
http://elsednice.skgo.org/.well-known/acme-challenge/...
Connection reset by peer

Other external clients can connect to port 80 normally, and the challenge URL is accessible externally with HTTP 200.

Could you please check why the HTTP-01 validation connection is being reset after the TCP handshake, before the HTTP request is sent?

I can provide the full tcpdump and Certbot logs if needed.

Thank you.

2

Welcome @sreckojovancevic

The "reset by peer" is something that happens at your end. The LE server is just reporting the failure.

It looks like something on your system is rejecting HTTP Challenge requests from the public internet. I can reproduce this using similar HTTP requests from my own test server. And, the responses vary depending on the "user agent" string I use. This is likely a firewall or other security setup at your location.

HTTP Challenge with user-agent similar to Let's Encrypt

curl -i http://elsednice.skgo.org/.well-known/acme-challenge/Test404 -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

curl: (56) Recv failure: Connection reset by peer

HTTP Challenge with "generic" user-agent

curl -i http://elsednice.skgo.org/.well-known/acme-challenge/Test404 

HTTP/1.0 500 Internal Server Error
Date: Fri, 04 Sep 2026 13:48:35 GMT
Server: Apache/2.4.41 (Ubuntu)

I successfully connect to your home page so the issue does not look like geographic based firewall filters or even IP based. It looks like something is interfering with the HTTP Challenges specifically.

Do you have a Palo Alto brand firewall by any chance? If not that what other devices or software do you have between the internet and the Apache server?

3

No it is not that means that the thing there in link is not on webserver the generated file does not sonisni need some generic folder file to be ther tell inwill put it

4

But you can see I get a "reset by peer" using a test from my own server when I use a user-agent string the same as Let's Encrypt. That means it is not related to how Let's Encrypt sends the request. It is something happening at your location.

Yet the same request using a different user-agent string gets a 500 error. Why does your system respond differently based on the user-agent?

The Let's Debug test site is helpful too. It runs a test from its own server and also gets a "reset by peer" from you. It then runs a test using Let's Encrypt staging system which fails the same.

An HTTP 404 is the more common response to a request for a file that is not found. In my experience this looks like a firewall or other device that is trying to handle an HTTP Challenge "in front of" where you run Certbot.

5

Yes i have pa 220

6

Make sure to enable the "acme-protocol" in your Palo Alto application settings.

This is likely the cause of the problem.

7

Done now works aded acme protocal app