Have been using CertSage 1.4 for the last 6 months with no issues. On trying to renew my Domains today I am receiving the following errors.
urn:ietf:params:acme:error:connection
92.205.0.183: Fetching http://holmes.uk.com/.well-known/acme-challenge/zKxMr44MoY2FlFxlg4YhJclV1awvPweeRpbn5PcO0Yg: Connection reset by peer
Hello @, welcome to the Let's Encrypt community. 
Using the online tool Let's Debug yields these results https://letsdebug.net/holmes.uk.com/1547659
Best Practice - Keep Port 80 Open
The HTTP-01 challenge of the Challenge Types - Let's Encrypt requires Port 80 to be Open and Accessible.
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:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Thank you for assisting us in helping YOU!
Looks like you have a firewall blocking specific IP addresses or ranges. I can reach your domain just fine on port 80 (http) and port 443 (https). But, Let's Debug reproduces your error consistently. Both its own http test and using Let's Encrypt staging server.
I checked the common cases for a Palo Alto brand firewall but do not see that as a problem. I mention this for benefit of other volunteers. Looks like a general firewall problem.
Using this online tool https://check-host.net/ gives these results Permanent link to this check report "Connection reset by peer"
And yet from my own test server in AWS East Coast region:
curl -I holmes.uk.com
HTTP/1.1 200 OK
Date: Wed, 12 Jul 2023 16:56:09 GMT
Server: Apache
curl -I holmes.uk.com/.well-known/acme-challenge/Test123
HTTP/1.1 404 Not Found
Date: Wed, 12 Jul 2023 16:56:57 GMT
Server: Apache
curl -I holmes.uk.com/.well-known/acme-challenge/Test123 -A "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
HTTP/1.1 404 Not Found
Date: Wed, 12 Jul 2023 16:57:03 GMT
Server: Apache
But, a fresh Let's Debug test shows its letsdebug-test http request getting the expected 404 now but staging request still fails.
Some sort of firewall. Possibly even an "adaptive" or "smart" one (which is set to be too aggressive)
+1
+2
Thanks for all your messages. my ISP is TSOHOST who got rid of automatic letsencrypt renewal for a yearly paid certificate. That is why I am using Certsage
So the fact that you suspect a firewall is blocking the requests could be an attempt by TSOHOST to close the Certsage loophole.
Sounds like a great reason to switch hosts. Make sure to let them know why.
No. I see something today that we have seen before with GoDaddy hosting sites. We've never gotten a clear explanation of why or how it gets fixed.
And, this problem happens with requests for your "home page" so not unique to ACME Challenge or Let's Encrypt.
This morning from my test server I first saw this:
curl -I holmes.uk.com
curl: (56) Recv failure: Connection reset by peer
curl -I holmes.uk.com
HTTP/1.1 200 OK
Date: Thu, 13 Jul 2023 13:40:25 GMT
Server: Apache
Upgrade: h2,h2c
curl -I holmes.uk.com/.well-known/acme-challenge/Test123
HTTP/1.1 404 Not Found
Date: Thu, 13 Jul 2023 13:40:47 GMT
Server: Apache
I get these same 200 OK or (expected) 404 Not Found if I repeat these requests rapidly after the initial 'reset by peer'.
But, if I wait 8 minutes my first request again gets 'reset by peer' followed by working responses. This is some sort of comms config issue with your hosting service.
It's possible waiting less than 8 minutes is enough to again see 'reset by peer' I just didn't test the limits. I think in prior threads just 2 or 3 minutes between was enough.
curl -I holmes.uk.com
curl: (56) Recv failure: Connection reset by peer
curl -I holmes.uk.com
HTTP/1.1 200 OK
Date: Thu, 13 Jul 2023 13:48:49 GMT
Server: Apache
Upgrade: h2,h2c
Hi Keith.
I just responded to you via email because I didn't see this thread. I'm very glad my colleagues here have been helping to diagnose the issue and I believe they're on the right track. If they're seeing the same behavior for your main website content, it's not an attempt to block CertSage. I suggest checking with TSOHOST about the general issue, but don't mention CertSage specifically since it's a general connectivity problem, not a CertSage operational problem.
Hi @Griffin,
Thanks for your reply. Not sure how to explain the problem to TSOHOST without mentioning Certsage. Do you have thoughts on this please.
Show them the sequence I showed in post #10. I could repeat the problem today with only a 2.5min wait time after success. These are just for your home page so have nothing to do with certsage.
curl -I holmes.uk.com
curl: (56) Recv failure: Connection reset by peer
curl -I holmes.uk.com
HTTP/1.1 200 OK
Date: Fri, 14 Jul 2023 13:20:50 GMT
Server: Apache
curl -I holmes.uk.com
curl: (56) Recv failure: Connection reset by peer
curl -I holmes.uk.com
HTTP/1.1 200 OK
Date: Fri, 14 Jul 2023 13:23:31 GMT
Server: Apache
Please provide TSOHOST the curl snippet from @MikeMcQ's post directly above. It illustrates the inconsistency with which your webserver can be reached in general.
Had a conversation with TSOHOST support which didn't go well. I pointed out the issues and provided the Curl code snippets. Support person suggested that I might want to change browser? I pointed out the connection was being reset but could not get any sense out the support person as to why this might be happening.
Sounds like you spoke to a TSOHOST employee not grasping the situation regarding ACME at all.
We tried to keep ACME (and CertSage) out of the discussion completely to keep TSOHOST from incorrectly pointing fingers at those specifically rather than addressing the general connectivity problem that's clearly present. 
Hmkay. Well, that might be a strategy. In that case you could interchange "ACME" with "curl" 
Or just forget I said anything at all
I reproduced this problem using a browser on Windows. So, not curl specific either. See below.
But, if they are willing to have users suffer having to reload the page they could get a cert using the DNS Challenge. Personally, I wouldn't want anyone to see the failure but we don't know how broad it is. I have reproduced using several different IP addresses but all in the USA, for example.
This is well beyond a question of getting / using certs. Still, I would be curious to learn a solution to more quickly help people. We've seen this a number of times now.
Here are example pics using Edge on Windows 10. I used a private window and reproduced this twice. Once with http:// and again (below) with https://.
First request
Immediately reloading page gets their home page
Thanks Guys I will give support another go later.
