Certbot failed - query timed out looking up CAA

Help
1

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. https://crt.sh/?q=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: play.37sur.com

I ran this command:

certbot --nginx -d play.37sur.com -v

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Requesting a certificate for play.37sur.com
Performing the following challenges:
http-01 challenge for play.37sur.com
Waiting for verification...
Challenge failed for domain play.37sur.com
http-01 challenge for play.37sur.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: play.37sur.com
Type: dns
Detail: During secondary validation: DNS problem: query timed out looking up CAA for play.37sur.com

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

nginx -v

nginx version: nginx/1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):

cat /etc/os-release

NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="Bugs : Ubuntu"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

My hosting provider, if applicable, is: Installed in own server

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot --version

certbot 3.0.0

2

I'm not entirely sure, but for some reason you have set ns1.37sur.com. and ns2.37sur.com. as NS records in your own DNS zone, even though there are no DNS servers listening on those hostnames, resulting in a timeout.

It looks like ns0.iperactive.com.ar. and ns1.iperactive.com.ar. are actually the authorative nameservers for your hostname and you should reflect that in your own DNS zone.

3 Likes
3

That may be a sign of Geo-Location blocking / Geo-Fencing.
[which should never be done on DNS service requests to authoritative DNS servers]

2 Likes
4

I do not believe that it is a Geo-Location blocking / Geo-Fencing as seen here Permanent link to this check report
however Let's Debug shows https://letsdebug.net/play.37sur.com/2280281

UnexpectedHttpResponse
Warning
Sending an ACME HTTP validation request to play.37sur.com results in unexpected HTTP response 403 Forbidden. This indicates that the webserver is misconfigured or misbehaving.
403 Forbidden

<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>


Trace:
@0ms: Making a request to http://play.37sur.com/.well-known/acme-challenge/letsdebug-test (using initial IP 186.0.180.143)
@0ms: Dialing 186.0.180.143
@483ms: Server response: HTTP 403 Forbidden
2 Likes
5

Yeah, I have a hypothesis that when the nameserver delegation is inconsistent, Let's Encrypt's Unbound resolver only complains some of the time, and so it will sometimes show up as a "secondary validation" just because it happened to be a time that the primary resolver worked and many secondary resolvers don't. I think that might also be why we see problems with inconsistent delegations more often than we used to around here, as when Let's Encrypt increased the number of secondary validation locations it also increased the number of chances for the problem to be exposed.

4 Likes
6

Hi all, thank you for your answers. We are working on the clues that provided us. We will back with the results as soon as possible.

1 Like
7

Hi all again, I could solve the issue. We add to domain's delegation n1.37sur.com and ns2.37sur.com records.
Thank all foru your answers and time.
Best regards!

3 Likes
8

Why would you do that? I already told you: there is NO DNS server listening at ns1.37sur.com. and ns2.37sur.com.. Why would you add them?

1 Like
9

Osiris, we have our own DNS (ns0.iperactive.com.ar and ns0.iperactive.com.ar). Also, 37sur.com is on a Plesk server. The transfer zone to that domain is our DNS server. Additionally, Plesk ask create n1.37sur.com and ns2.37sur.com records in out DNS. Knowning that, we added in the platform where we registered 37sur.com the server n1.37sur.com and ns2.37sur.com (It had already defined ns0.iperactive.com.ar and ns0.iperactive.com.ar). After that change, cerbot worked.

10

Those two are working indeed.

I'm not sure what you mean by this.

Why would Plesk ask you to do that? There are NO DNS servers running on those hosts.

Why?

Yes, those are actually the authorative DNS servers for your domain 37sur.com. It responds with the SOA RR.

Then I guess the thing I saw was not the issue, because you've made it worse. Please let someone with actual experience and knowledge of DNS look at it.

3 Likes
11

Ok, I will that. Thanks for your help.

1 Like
12

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