Problem with verification

Issuance Tech
#1

Hi. I represent the hosting operator company.

Our clients’ servers have problems with verifying domain names on your service. We tried various methods of domain verification, through dns, acme-challenge, through certbot software.
Returns an error: DNS problem: query timed out looking up A for domain.com

We have our own firewall with a lot of blocked addresses. I already read on the forum that these domain names are used for verification:
acme-v01.api.letsencrypt.org
acme-staging.api.letsencrypt.org
acme-v02.api.letsencrypt.org
acme-staging-v02.api.letsencrypt.org
Pings from servers behind the firewall pass. Your servers have a large number of ip addresses, is it possible to find out a list of these addresses to add to our firewall?

#2

Answered here: https://letsencrypt.org/docs/faq/#what-ip-addresses-does-let-s-encrypt-use-to-validate-my-web-server

The hosts that you listed are not the ones involved in performing domain validation - they are just API endpoints.

Whitelisting the validation hosts isn’t a viable solution in the long run.

#3

you validate the web server from several ip addresses, if one of the addresses falls under the firewall, then the check will not be successful? Do you check the client server itself or nameserver of hosting provider? or does it depend on the verification method?

#4

Today, there are 4 checks in total: 1 from a primary validation location, and 3 from secondary validation locations.

The primary location must always succeed to validate the challenge, and at least 2 out of the 3 secondary locations must succeed. Currently, the secondary locations are all hosted on AWS, but in different regions.

These details are subject to change. (Source).

All of the validation methods require DNS lookups.

Let’s Encrypt runs recursive DNS resolvers at each of the 4 locations.

So when you perform any challenge for a domain, each of the 4 DNS resolvers will send DNS queries to the domain’s authoritative nameservers.

For HTTP validation, in addition to the DNS lookups as described above, you will also see 4 HTTP requests to the webserver hosting your domain, one from each validation location.

(I would add, that this does not mean there are only 4 IP addresses. There are multiple IP addresses at each location).

With this error specifically, this means that not enough of the validation locations succeeded in performing the DNS lookup of your domain.

This means either:

  • The primary validation location failed to get a response to its DNS queries, or
  • More than 1 of the secondary validation locations failed to get a response to their DNS queries
#5

Are there any domain names associated with your primary and secondary validation locations, so that at any point in future we could check their IP addresses?

#6

Let’s Encrypt has specifically decided not to support firewall whitelisting of validation servers.

It’s very easy to find out what the IP addresses currently used are, but very difficult to get any cooperation from Let’s Encrypt or the forum volunteers here in whitelisting them, because that’s explicitly discouraged and unsupported.

1 Like
#7

No. You should use dns-01 validation.

#8

i’ve used dns-01 validation, it returns:
warning: Your verification URL is not returning the correct contents to our verification servers. The URL looks like it is blocking bots and which inadvertently blocks our servers from receiving the correct content. Contact your host, a professional developer or admin for further help with fixing it.

as i read on forum, this problem appears because of the WAF. is there any other solutions how we can find validation server’s ip addresses?

#9

I think that error message comes from SSL For Free? It’s not from Let’s Encrypt.

DNS-01 validation doesn’t make HTTP requests. You can’t possibly get an error like that when using it.

Can you fill out as much of the questionnaire below as you can?

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:

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

#10

I represent the hosting operator. therefore, we know that the problem is in WAF, but we cannot solve it to the end. our last action was to whitelist our nameservers on 53 DNS port, but this did not help. Does the Let’s Encrypt use ports other than 53 validate domain on nameservers?

#11

This hook script (originally for Alpine Linux) might help you in getting DNS-01 challenges to work.

#12

I still don’t understand. You’re talking about Web Application Firewalls and DNS, which operate on different layers.

Can you respond to my previous post?

#13

Hi @ilyas

if you want help, your domain name is required.

Using dns validation manual - a lot of errors are seen.

#14

My domain is: certbottest.com.tm (or any other .com.tm domains)
I ran this command: sudo certbot certonly --apache

It produce this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for certbottest.com.tm
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. certbottest.com.tm (http-01): urn:ietf:params:acme:error:dns :: DNS problem: query timed out looking up A for certbottest.com.tm

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: certbottest.com.tm
    Type: None
    Detail: DNS problem: query timed out looking up A for
    certbottest.com.tm

My web server is - Server version: Apache/2.4.18 (Ubuntu)
The operating system my web server runs on is - Ubuntu 16.04
My hosting provider is - i represent hosting provider
i can login to root shell on my machine - yes
I’m using a control panel to manage my site - no, it is a VPS without panel
The version of my client is - certbot 0.31.0

I tried the proccess with DNS-01 validation on sslforfree.com too, another output:
Warning: Your verification URL is not returning the correct contents to our verification servers. The URL looks like it is blocking bots and which inadvertently blocks our servers from receiving the correct content. Contact your host, a professional developer or admin for further help with fixing it.

Error: DNS problem: query timed out looking up TXT for

I know that this problem is because of WAF, our ns servers have rules to block incomming trafic for a lot of ip addresses. we tried to white list them on 53 dns port (we thought that let’s encrypt servers use this port for validation). We cant open all incoming trafic for our ns servers.

We had success validation and getting ssl certificates in February i think.

#15

That problem isn’t visible - your domain has an A record - https://check-your-website.server-daten.de/?q=certbottest.com.tm

http validation should work or should produce another error, /.well-known/acme-challenge/random-filename sends not the expected result 404, instead a wrong 403.

But some tm name servers are buggy:

X Nameserver Timeout checking Echo Capitalization: ns-d1.tm
X Nameserver Timeout checking Echo Capitalization: ns-l1.tm
X Nameserver Timeout checking EDNS512: ns-d1.tm
— —
X Nameserver Timeout checking EDNS512: ns-l1.tm

Curious: Unboundtest is happy - https://unboundtest.com/m/A/certbottest.com.tm/NSTSXGEM and has the A record:

;; ANSWER SECTION:
certbottest.com.tm. 0 IN A 95.85.120.65

Letsencrypt uses an Unbound version with the same configuration, so Letsencrypt should find your A-record.

And there is no TXT record - see the #txt part:

2020-04-28.certbottest.com.tm
2020-04-28.certbottest.com.tm917×182 4.39 KB

Should look like

server-daten.de.correct.txt.definition
server-daten.de.correct.txt.definition1127×409 14.8 KB

#16

i deleted previous dns record, tried again now too, same error:
Domain “certbottest.com.tm” challenge3 failed. Response from “https://acme-v02.api.letsencrypt.org/acme/chall-v3/4227906509/b3z5ig” was:

Warning: Your verification URL is not returning the correct contents to our verification servers. The URL looks like it is blocking bots and which inadvertently blocks our servers from receiving the correct content. Contact your host, a professional developer or admin for further help with fixing it.

Error: DNS problem: query timed out looking up TXT for _acme-challenge.certbottest.com.tm

Full Error: { “type”: “dns-01”, “status”: “invalid”, “error”: { “type”: “urn:ietf:params:acme:error:dns”, “detail”: “DNS problem: query timed out looking up TXT for _acme-challenge.certbottest.com.tm”, “status”: 400 }, “url”: “https://acme-v02.api.letsencrypt.org/acme/chall-v3/4227906509/b3z5ig”, “token”: “zkJ8fKB30QwWdwJig5R1AKUAKSl8yehWKXMrFyBfmvc” }

You can check DNS records

We user other nameserver:
webns1.telecom.tm
webns2.telecom.tm

#17

I know. Read the complete output of the online check.

If you have changed your configuration -> recheck your domain.

#18

Warning: Your verification URL is not returning the correct contents to our verification servers. The URL looks like it is blocking bots and which inadvertently blocks our servers from receiving the correct content. Contact your host, a professional developer or admin for further help with fixing it.

yes, i represent hosting provider, so we want to unblock your bots.

previously you said that there is not specific ip addresses list with validation server, so we white listed all the ip addresses for specific port - 53 DNS port. but no luck. can you tell which port use your bots for validation?

#19

Authoritative DNS servers always use port 53.

Clients use random ports. (Or at least good ones do.)

#20

On port 53, but not only UDP, TCP is needed as well. The UDP packet size may exceed the size limit (for example with DNSsec easily) , and clients retry with TCP. TCP is a MUST for DNS.

1 Like