Impossible to receive a new certificate or renew previous certificates

Our company offers online site building tools like
To date, we have received certification through for over one hundred and fifty sites from our subsidiary.

Previously, we had to create a new account each time to resolve our problem to get a new certificate or renew the certificate.

But this time the problem has reappeared and the previous solution is not working.

My domain is:

I ran this command: ssh: ./ request_single, 4096

It produced this output:
Generating 4096 bit RSA key for let’s encrypt account…
openssl genrsa 4096 > “/usr/local/directadmin/conf/letsencrypt.key”
Generating RSA private key, 4096 bit long modulus
e is 65537 (0x10001)
Account has been registered.
Requesting new certificate order…
Processing authorization for…
Waiting for domain verification…
Let’s Encrypt was unable to verify the challenge. Unable to update challenge :: authorization must be pending. Exiting…

My web server is (include version): Apache (v: 2.4.28) && Nginx (v: 1.13.6) as Reverse Proxy

The operating system my web server runs on is (include version): CentOS 6.0 64-Bit

My hosting provider, if applicable, is:

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): DirectAdmin (v: 1.60.4)

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

1 Like

If you click on the link of the authorization, you can see the error message:

During secondary validation: DNS problem: SERVFAIL looking up A for - the domain’s nameservers may be malfunctioning

1 Like

Thank you for your attention

Yes, I’ve read the description of this link before, but I don’t understand exactly what the problem is.
Please help more.

One of the DNS servers at a site of secondary validation received an error message from your DNS server or one of the DNS servers in between.

I can’t reproduce this error from my end, nor from

Perhaps someone from @lestaff could give more information about this specific case? (I have seen this a few times before: DNS errors from secondary validation sites not reproducable from either my end nor from unboundtests end.)

1 Like

I can confirm that appears to be consistently failing remote validation, but I can’t really say why - it could be routing issues from one or more of our remote validation perspectives, or it could be an anti-DDoS appliance, or it could be misconfigured firewall rules. I do notice some problems with the DNS config for this domain name:

$ dig ns

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2079
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

; EDNS: version: 0, flags:; udp: 512
;                 IN      NS

;; ANSWER SECTION:          14400   IN      NS          14400   IN      NS

;; ADDITIONAL SECTION:        3599    IN      A

The ADDITIONAL SECTION (often called “glue”) should contain entries for both and

Also, ns1 and ns2 are the same IP address. For reliability you actually want two different IP addresses:

$ dig +short
$ dig +short

One last thing: I noticed in our logs that the User-Agent header your client sends is “AppleNewsBot.” That suggests to me that you are probably writing your own ACME client, and possibly repurposing some existing code from a different program. Is that right? If so, I’d definitely recommend trying to use one of the existing ACME clients listed at I think you will have a much easier time, since those clients will already have fixed a lot of bugs. They will probably be more reliable, faster, than any client you write yourself.



Another option is that on the system used, for that user there exists a default cURL configuration file with that useragent set. Perhaps for some other debugging. Not saying it is, but it could be, as the DirectAdmin script we see in the first post uses cURL as the client.


To test another domain, we activated it on our server, but we put the IP differently from the IP of our other sites:
We also turned off the firewall and also used, which is introduced in the ACME Client Implementations page, but again we got the same results as before: :broken_heart:
Can you give me some new tips?

Now, about the same site,
Is it possible to test manually to see if this file is visible and valid?
Perhaps a conclusion can be drawn.
This file is also a certificate request, but there is an invisible objection to it:

1 Like

Hi @poopesh

the error

During secondary validation: DNS problem: query timed out looking up A for

looks like your name server has a firewall that blocks some regions.


I confirm that the IP address is having trouble to reach from certain places:

It is worthwhile to contact the ISP of the IP.


Did you resolve the issue?
I have exactly the same problem for all of my let’s encrypt certificates (until now 40 domains).
I got into trouble …
BAD one…

1 Like

Unfortunately, we have not yet found a solution because we do not know exactly where the problem is.

1 Like

I’ve informed that you are using “Faraso” infrastructure, we are so.
did you call them?
call them and share their answer here or in

1 Like

Yes, they were given access to the server. They may have fixed the problem, but they couldn’t.
We had a problem a month ago, and by changing the procedure, we solved the problem so that a new account could be created for each certificate.

Can we get more information from you?

1 Like

With a series of changes made to the network (outside the server), the problem is solved.

Thank you all dear ones. :heartpulse:

1 Like

Letsencrypt uses the Amazon Cloud (AWS) for secondary validation. If you mass block AWS in your firewall for some reason (there’s a long list of good reasons) then unblock AWS to test if this is your problem.


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