7

I have been using Let's Encrypt on a few domains for a couple of months now, and it generally has been working. I was going through renewing the certs, and for one of the domains I get the following error message (in the returned JSON object at challenges[1].error.detail):

DNS problem: query timed out looking up CAA for [somedomain.com]

I tried looking up the error, but even Google found zero results (as of this writing). For the naysayers: Yes, this domain (exactly as shown in the error message) is valid and fully accessible and pingable from afar.

There is an important predicament (clue) here, however, as to why this condition has sprung up. I had the settings for this domain set to redirect all traffic to HTTPS when I first tried renewing this particular domain. It seems that LE tried accessing the server at the HTTPS and failed. Since then I have changed the server settings so that the domain is not redirected to HTTPS for the acme-challenge folder. The problem seems to be that LE is remembering that a previous request was redirected, and now it does not want to access the HTTP URL instead. The challenges[1].validationRecord has two entries, one at [0] for HTTP and one at [1] for HTTPS, so clearly LE is aware that the server can be accessed at the HTTP address as well. Moreover, I can access the validation check file (on the domain in question) at the URL as given in challenges[1].validationRecord[0].url just fine without any issues.

My question is: How do I make LE forget that I tried requesting a cert while having the server set to redirect all traffic to HTTPS? Hence, how do I make LE use the HTTP URL instead?

Michael
  • 231
  • 2
  • 8
  • Have the same message - but only on renewal. If I delete my virtual LE folter (/root/.local/share/letsencrypt) and run the command it succeeds... one(!) time! – cljk Feb 08 '16 at 21:43
  • Same mgs here. Reason: trying to create a cert like this: "-d xmpl.com,xmpl.net". Only the DNS for xmpl.net was updated, with an xmpl.com update still missing. This lead to "--dry-run" being successful but certbot fail when really creating the cert. Before DNS was fully updated, I used "-d xmpl.net" and later on extended the cert. – Gen.Stack Dec 28 '21 at 21:41

3 Answers3

2

Let's Encrypt doesn't keep track of previous redirects. You can either use the HTTP or HTTPs version for validation.

Your error highlights a different problem

DNS problem: query timed out looking up CAA for [somedomain.com]

The validation system was not able to complete a DNS lookup of the domain. It may be possible that the DNS provider you are using had some problem, or that the route between Let's Encrypt servers and your server had some network issue.

This is a similar problem, described on the official LE community forum.

I think the problem is on the DN look-up step. There is no CAA record. Somehow it took very long time for domain name server to respond. Here are some results Osiris sent to me. He mentioned that getting ip is fast, but 'one but last step is often quite slow'. Slowness could be the reason for failing at CAA checking step.

and

Based on the original error and those times, it's very likely there are some problems with the DNS servers you're using or the route to them from Let's Encrypt's data center, and it's causing timeouts.

Investigate your DNS settings, and if the lookup is successful retry to submit the certificate request after some time.

Simone Carletti
  • 1,524
  • 3
  • 15
  • 30
  • The domain in question does not have a CAA record, nor do the other domains for which I updated the certs at this time. Perhaps there was a problem with the DNS server at that time. If the error happens again next time I try updating the cert, I can check the DNS server for that domain. If this really is a generic DNS failure, the error message really should not mention CAA since that implies the use of CAA, when I am pretty sure most domains have none. Moreover, I ended up getting the cert renewed *by putting an old (still valid) certificate on it* -- implying that LE *was* requiring HTTPS. – Michael Jan 28 '16 at 16:18
  • I changed the DNS Server in the DNS settings of the domain, and it works. – oudi Apr 10 '23 at 05:35
0

I got this error after switching to a new server machine (different IP).

While renew command failed with the error above.

Running certbot with certonly command worked (not sure why!).

schettino72
  • 101
  • 2
0

Up-to-date version of acme client usually display the target ip that timed out. It appears that the client issues queries to different name servers during the certificate request routine. Those server include but not limited to the default DNS server for the machine, and the authoritative name server of the domain you are using.

I've seen a situation, when with otherwise perfect network connection the route to the authoritative name server was blocked on the company firewall. (I know, weird). So while all names (including this particular domain) resolved perfectly, when acme client tried to contact the authoritative name server directly the process failed. That was resolved by changing the firewall rules to let the request through.

So for year 2018 and later - look at the logs, they usually tell you what ip address times out and check connectivity from acme client to that address.

Andrew Savinykh
  • 526
  • 2
  • 7
  • 21