Connection reset by peer - error updating SSL certificate

Hello

My domain is: mederi.buap.mx

I ran this command: ./certbot-auto certonly --webroot -w /srv/www/htdocs/ -d mederi.buap.mx

It produced this output:
Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for mederi.buap.mx
Using the webroot path /srv/www/htdocs for all unmatched domains.
Waiting for verification...
Challenge failed for domain mederi.buap.mx
http-01 challenge for mederi.buap.mx
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: mederi.buap.mx
    Type: connection
    Detail: 148.228.12.25: Fetching
    http://mederi.buap.mx/.well-known/acme-challenge/54tzbWhu5Vc_zmz3toL4DFhX5IN1wGz9WucVddBl6aM
    Connection reset by peer

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you're using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version): Apache

The operating system my web server runs on is (include version):Linux 3.16.0-10-amd64 #1 SMP Debian 3.16.81-1 (2020-01-17) x86_64

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.9.0

AAAANNNDDDD

I also tried to renew the certificate using getssl and got the following response:

root@mederi:/srv/www/certs/getssl# ./getssl mederi.buap.mx

Registering account

Verify each domain

Verifying mederi.buap.mx

copying challenge token to /srv/www/htdocs/.well-known/acme-challenge/3UA8wvepzzQ2-4rY60fC-ZH3cDT5K6DcE546q4HtQ1s

sending request to ACME server saying we're ready for challenge

checking if challenge is complete

Pending

checking if challenge is complete

getssl: mederi.buap.mx:Verify error: "detail": "148.228.12.25: Fetching http://mederi.buap.mx/.well-known/acme-challenge/3UA8wvepzzQ2-4rY60fC-ZH3cDT5K6DcE546q4HtQ1s Connection reset by peer",

I don't I don't know what's happening because I just want to renew, I have been using let's encrypt for many years as you can see it: crt.sh | mederi.buap.mx

help me please,

Hi @valar.ainur, and welcome to the LE community forum :slight_smile:

It is very likely that there is some GeoLocation blocking the requests.

2 Likes

You are almost certainly affected by a Palo Alto brand firewall.

You need to change the Palo Alto firewall to allow "acme-protocol" in its Applications section. Show your network team the two requests below. Both should result in a 404 but you can see the one with the user-agent like LE fails. We have seen this problem often.

# With a user-agent like Let's Encrypt - it fails
curl http://mederi.buap.mx/.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

# Without that user-agent, it works
curl http://mederi.buap.mx/.well-known/acme-challenge/Test404
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
6 Likes

The work team in charge of network permissions tells me that they have not made any changes or adjustments to the FW environment policies since 4 months ago.

Is there any other possible suggestion that could perhaps be applied directly to my server (mederi.buap.mx) in the apache configuration file httpd.conf or directive with .htaccess ?

No; The evidence is quite clear.
If they have a Palo Alto firewall, then the problem is within it.
That they haven't made any changes to it in four months, is irrelevant.
They claim no policy changes.
This is NOT a policy change - it is an IPS signature update that causes this issue.
It might have updated itself automatically.
It might have been less than 4 months ago when they made their last change.
It might be whatever...
It is definitely a Palo Alto firewall issue.

4 Likes

Thanks a lot.. for your time and suggestion.

I will continue to insist with the network department of my university to solve the problem, I still have one day left on the certificate license :-S

3 Likes

Show your network team the two example curl commands I provided.

They should be able to check the firewall logs to see one of those connections dropped.

The problem started when Palo Alto introduced a new config setting. They set the default to reject these kinds of http requests.

We have seen cases at universities where there are 2 Palo Alto firewalls. One at the outer edge and one at say a department level. Your network team should be able to help locate where the request gets rejected.

6 Likes

That's right, the problem was solved, the firewall was blocking the acme protocol...
The firewall was blocking the Acme protocol, but with the permissions open, the renewal was done successfull.

Very thank you for your comments and suggestions.

3 Likes

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