Connection reset by peer on macOS apache, including LetsDebug

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: medyan.org

I ran this command: (1) letsdebug.net > medyan.org, or (2) sudo certbot certonly --webroot. (3) I also tried on another machine: curl -I http://medyan.org/.well-known/acme-challenge/letsdebug-test.

It produced this output: (1)(2) In both cases, the challenge fails with "Connection reset by peer". (3) However, using curl command, I am receiving 404 because I do not have that file, but I am at least having a successful HTTP conversation instead of a TCP reset:

HTTP/1.1 404 Not Found
Date: Mon, 15 Aug 2022 23:04:41 GMT
Server: Apache/2.4.54 (Unix) OpenSSL/1.1.1p
Content-Type: text/html; charset=iso-8859-1

Also when I am using LetsDebug, I get these two lines in my access_log:

172.104.24.29 - - [15/Aug/2022:19:26:26 -0400] "\x16\x03\x01" 400 226
172.104.24.29 - - [15/Aug/2022:19:26:26 -0400] "GET / HTTP/1.1" 200 7274

My web server is (include version): Apache/2.4.54 (Unix)

The operating system my web server runs on is (include version): macOS 11.4 (firewall is Off in settings)

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

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

2 Likes
2

Hi @drelatgithub, and welcome to the LE community forum :slight_smile:

It seems like you may have made some progress:
image

But the HTTPS (port 443) connections are "clear text":
image

2 Likes
3

Thanks! Yeah that was because Listen 443 was configured in httpd.conf. I just removed that line so http://medyan.org:443 will no longer work. However, AFAIK the challange only requires a working 80 port, so 443 is only necessary after I receive a certificate.
It seems that I can freely access all files in .well-known/acme-challange all right using a browser or curl, and only LetsEncrypt traffics cannot get through for some reason. Now, with or without Listen 443 LetsDebug reports the same errors.

3 Likes
4

Do you have anything that does Geo-location blocking/fencing?

3 Likes
5

Thank you! I do not think I have anything like that installed on the computer. I do not have control beyond the server, but do you think upper stream devices could do that as well?
I will try to move the server to another computer tomorrow and see whether it fixes anything.

3 Likes
6

I suppose so:

Name:    medyan.org
Address: 129.2.147.12

Name:    papoian.chem.umd.edu
Address: 129.2.147.12
3 Likes
7

Yes. I have set up 3 vhosts on this server. However, all of the domains have the same problem as described above. All of them are configured the same way. Would that be an issue though? Thanks!

2 Likes
8

You likely have a Palo Alto Networks brand firewall causing this trouble.

We have seen many similar problems due to this brand of firewall as they changed a default setting earlier this year. You should have your network team check for an Application Rule for "acme protocol" and allow that.

The symptom is that I can make a test request to your server similar to what the Let's Encrypt server makes before issuing a cert. And, the test succeeds. BUT, only if I do not use the same user-agent as the Let's Encrypt server uses. If I do that the request fails with 'reset by peer'.

Here are sample curl requests you can provide to your network team to test the fix. These results are repeatable.

curl -I medyan.org/.well-known/acme-challenge/Sample123
(this should be 404 Not Found because Sample123 is not on your server)
HTTP/1.1 404 Not Found
Date: Tue, 16 Aug 2022 03:13:19 GMT
Server: Apache/2.4.54 (Unix) OpenSSL/1.1.1p
Content-Type: text/html; charset=iso-8859-1

curl -I medyan.org/.well-known/acme-challenge/Sample123 -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
curl: (56) Recv failure: Connection reset by peer
4 Likes
9

Thank you so much for this! I will try to contact the network team to see whether they could help resolve the firewall issue!

4 Likes
10

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