First of all, redacting your domain name just makes it harder for people to help you out. And it's listed in the link to the authorization details you posted anyway.
"Connection refused" means just that, when trying to connect to your system it was refused, so Let's Encrypt's servers couldn't verify that you control it.
For details on how Let's Encrypt checks, and what you need to allow in order for them to validate you control the domain name, this may help you:
Let's Encrypt wants to see your website as it appears to the rest of the internet.
I would check again, you could have multiple firewalls.
You should answer the questions in the template:
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):
As to whitelisting...maybe that was the wrong term. How can I setup my firewall to allow Let's Encrypt regardless of my ruleset? Is there a DNS capability?
Traditional firewall, that's not going to be possible. If you use modsecurity or similar, just allow connections to yourdomain.example/.well-known/acme-challenge/ from everywhere.
Is the site intended to be publicly accessible? It isn't now, and the most common way to get a certificate (called HTTP-01) requires Let's Encrypt to be able to connect to the site.
If it's intended to be something for a limited audience, but the authoritative DNS server is going to be accessible, then you can use DNS-01 instead.
I'm not familiar with Plesk, but if it handles both your web site and your authoritative DNS, then I think it can do the DNS-01 challenge. The core idea is that the system requesting the certificate needs to be able to programmatically update the DNS zone, which is sometimes really easy and sometimes very hard. I'm not sure options your system gives you access to.
So my DNS is handled with Cloudflare and yes it is intended to be publicly available. It is not now bc there is no certificate attached to the site. Cloudflare points to the right public IP, as I double checked that. I had been using the Plesk interface for other certificates and it was working, so not sure about Plesk being in the way. I thought maybe some of my firewall rules were getting in the way, since I have a full on global blacklist. I only allow from US and Canada.
That is too limited for Let's Encrypt HTTP Challenges now (*1). There was a change in April to add additional non-USA validation centers and at least one of these must succeed along with the others.
Peter's "Multi-Perspective ..." link in post #2 has the whats and whys.
This part of that thread talks about the recent change
*1) It would also be too limited for authoritive DNS servers behind such a firewall and using the DNS Challenge. It just is not as typical to see DNS Servers firewalled like that but we do see it sometimes.
The result link from Let's Debug is helpful so we can see the Verbose output that it also offers.
It does a connection test from its own server and that is what looks to be failing. It also uses the Let's Encrypt Staging system to make a test cert request. This will fail to get a cert (because Let's Debug cannot control your server) but the kind of failure can give clues to problems.
From my own personal test server running in an AWS US East Coast region I cannot connect to your regulatory domain at all. Port 80 requests are refused and port 443 fail and looks like no server is listening.
curl -i http://regulatoryintelligence.com
curl: (7) Failed to connect to regulatoryintelligence.com port 80 after 54 ms:
Connection refused
curl -i https://regulatoryintelligence.com
curl: (7) Failed to connect to regulatoryintelligence.com port 443 after 5121 ms:
No route to host
I have pulled out all rules, NATs, and other things from my firewall. I am now going to put it back together one by one. With that said I used Lets Debug with DNS-01 and got a green no issues found. What does that tell me??
Sorry...put the verbose in bc of what staging said.
Ok I am going to take the small win and stop now. Its time for bourbon, a cigar, and a NY Knicks win. I can build off this. I suspect i modified a rule that caused this all to go wonky. It also doesn't help that we were using Cloudflare proxy and are not quite done with them.
