Status: 400
Detail: During secondary validation: DNS problem: query timed out looking up CAA for aidat.pro
[2020-03-15 22:53:53.861] ERR [extension/letsencrypt] Domain validation failed: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/3378144459.
Details:
Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: During secondary validation: DNS problem: query timed out looking up CAA for aidat.pro
Only the server’s main ip address has been changed. How can we fix it?
Thanks @mnordhoff for hinting AWS issue. Have arrived here with the same (comparatively recent) problem on all our servers, resolved by bulk deleting AWS IPs from firewall.
AWS is a well known hub of spammers, scrapers, bots & all sorts of nasties. We increasingly faced a non-stop storm of all sorts of “attacks” from AWS IPs, getting involved in a futile wack-a-mole campaign of banning individual offending IP ranges - till we decided to block en masse all AWS known IPs and thus get some peace of mind.
Since overall we are not aware of what Letsencrypt IPs to whitelist, we are forced to weaken our firewall to a great extend to be able to use Letsencrypt.
Unwittingly Letsencrypt, dedicated to web security, is in effect exposing our servers to security issues by weakening by some of its decisions some of our firewall defenses.
I am not advocating here publication of IPs to whitelist. They have indeed to remain secret. However, Letsencrypt IPs should be far, far away from clusters candidate for IP range blacklisting such as AWS, Google, Microsoft, Oracle, Hetzner and other such nasty clouds.
If your network's security depends on an absolute blacklist of AWS IPs, there are other, more serious, problems with your network security. But if this concerns you, there's a simple answer: use DNS validation.
@danb35 : Thanks, however I’m afraid you’re missing the point. Our over 20-year server invincibility has convinced us we are doing something right security-wise, including not snubbing a few low-tech measures - such as using (among others) a medical mask and washing hands in the Age of Covid-19 to block the virus. Limiting exposure helps. Why let nasties knock at your door when you may block them at the highway?
And avoiding avoidable hoops, especially when a large number of domains is involved over multiple servers.
Thanks @JuergenAuer, however beg to differ. On the premise there is no 100% security anywhere, not on the web, not in the real world, limiting exposure by eliminating avenues & raising multiple barriers, is prudent in security. Certainly, not as exclusive defense. Eventually, as things stand, if sever is truly worth hacking (ex. bank) it may be hacked. Our servers, glad to say, are not worth the volume of trouble required to hack them, due to (among others) limited exposure. This includes blocking all countries not interested in, and server clusters known as trouble hubs. Little value, if any, exposing ourselves to the likes of AWS. Cost of blocking them, negligible. All “for fun & glory” efforts against us, as well as for-profit ones, have to date failed miserably.
(Hope this doesn’t sound like a lecture, not meant to be. Despite experience, learning new things by the day, full of ears!).
My point: believe Letsencrypt better avoid verifying from AWS IPs or any such extensive cloud known open to abuse, and liable to firewall blocking.
Letsencrypt rightly limits exposure by not publicizing its IPs for whitelisting. Others have similar concerns, which should not be snubbed. Maybe it’s not exactly the same, but in principle it’s the same.
Last, but not least, valid reason for our blocking entire undesirable server clouds is the considerable server resource drain caused by bots, spammers, scrapers, etc, operating from them. Prior to mass blocking server clouds, most of our server resources & bandwidth were drained by such undesirables while true human traffic required just a fraction of our computing power.
We had a spectacular improvement of this situation by such blocking & limiting our exposure, without any loss of business and at the same time significant server performance improvement.
AWS, where Letsencrypt verifies from, had 1250 ranges blocked by us. Reduction of undesirable “traffic” originating from AWS was unbelievable. However, we needed to re-open the floodgates to this hell to keep Letsencrypt functional.
Hopefully, Letsencrypt will take this point into consideration, and hide its IPs in locations not susceptible to essential blocking.