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):
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.
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.
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.
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.
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://.