Issuance of Certs

Hello all,

We are testing our new websites and I went to re-issue a cert and it failed giving me the following:

Could not issue an SSL/TLS certificate for tld.example.com
Details
Could not issue a Let's Encrypt SSL/TLS certificate for tld.example.com. Authorization for the domain failed.
Details
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/351979533077.
Details:
Type: urn:ietf:params:acme:error:connection
Status: 400
Detail: 144.202.185.221: Fetching http://tld.example.com/.well-known/acme-challenge/QztSSjlNkU_rzONavb80WzM3XWwi2jaQ1HyZc63uLS0: Connection refused

Not sure why it would be refused...any thoughts? I have turned off any firewall related items.

Thanks,
Steve

1 Like

The other part of this is how can I whitelist Let's Encrypt? Is there a document on what to do? I would like to do that also.

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. :slight_smile:

"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:

5 Likes

You don't. :slight_smile:

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

5 Likes

Ok apologies...I really did not know how to go about doing this, so I should have followed the template. Here is the info requested.

1 Like

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.

5 Likes

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.

4 Likes

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.

3 Likes

OK in doing some testing with Let's Debug I am getting this:

ANotWorking
ERROR
regulatoryintelligence.com has an A (IPv4) record (144.202.185.221) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
A timeout was experienced while communicating with regulatoryintelligence.com/144.202.185.221: Get "http://regulatoryintelligence.com/.well-known/acme-challenge/letsdebug-test": context deadline exceeded

Trace:
@0ms: Making a request to http://regulatoryintelligence.com/.well-known/acme-challenge/letsdebug-test (using initial IP 144.202.185.221)
@0ms: Dialing 144.202.185.221
@10001ms: Experienced error: context deadline exceeded

I have turned off everrything that should be HTTPS. I have shut HSTS. I have turned off HTTP to HTTPS. I am thoroughly confused here.

regulatoryintelligence.com does have a valid Let's Encrypt on it, so I am not sure whats going on.

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
3 Likes

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??

Not much. That is a very limited test. It offers some assistance for people using the DNS challenge

Click the verbose link at the bottom of the result page to see the specific tests performed

3 Likes

OK making progress...

I got HTTP-01 to go green. Here is the verbose. Should I be concerned about what is said under Let's Encrypt Staging?

## Test result for regulatoryintelligence.com using http-01

CAA

DEBUG

CAA records control authorization for certificate authorities to issue certificates for a domain

regulatoryintelligence.com. 0 IN CAA 0 issue "letsencrypt.org"
regulatoryintelligence.com. 0 IN CAA 0 issue "pki.goog; cansignhttpexchanges=yes"
regulatoryintelligence.com. 0 IN CAA 0 issue "comodoca.com"
regulatoryintelligence.com. 0 IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes"
regulatoryintelligence.com. 0 IN CAA 0 issuewild "comodoca.com"
regulatoryintelligence.com. 0 IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
regulatoryintelligence.com. 0 IN CAA 0 issuewild "letsencrypt.org"
regulatoryintelligence.com. 0 IN CAA 0 issuewild "pki.goog; cansignhttpexchanges=yes"

HTTPCheck

DEBUG

Requests made to the domain

Request to: regulatoryintelligence.com/144.202.185.221, Result: [Address=144.202.185.221,Address Type=IPv4,Server=nginx,HTTP Status=301,Number of Redirects=1,Final HTTP Status=404], Issue:
Trace:
@0ms: Making a request to http://regulatoryintelligence.com/.well-known/acme-challenge/letsdebug-test (using initial IP 144.202.185.221)
@0ms: Dialing 144.202.185.221
@216ms: Server response: HTTP 301 Moved Permanently
@216ms: Received redirect to http://www.regulatoryintelligence.com/.well-known/acme-challenge/letsdebug-test
@1310ms: Dialing 144.202.185.221
@1525ms: Server response: HTTP 404 Not Found

HTTPRecords

DEBUG

A and AAAA records found for this domain

regulatoryintelligence.com. 0 IN A 144.202.185.221

LetsEncryptStaging

DEBUG

Challenge update failures for regulatoryintelligence.com in order https://acme-staging-v02.api.letsencrypt.org/acme/order/5751349/16598592414

acme: error code 403 "urn:ietf:params:acme:error:unauthorized": 144.202.185.221: Invalid response from http://www.regulatoryintelligence.com/.well-known/acme-challenge/XNxMTA5hoOisa7wvO1thLWv1PdQaVCIVbAvY6FyW_Fc: 404

PublicSuffix

DEBUG

The IANA public suffix is the TLD of the Registered Domain

The TLD for regulatoryintelligence.com is: com

StatusIO

DEBUG

The current status.io status for Let's Encrypt

Operational

Good progress. No that staging test got the expected result. It is easier if you just post the URL of the result page like this

2 Likes

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.

1 Like