Our company offers online site building tools like wix.com To date, we have received certification through letsencrypt.org 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.
I ran this command: ssh: ./letsencrypt.sh request_single fotozibano.ir,fotozibano.ir 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 https://acme-v02.api.letsencrypt.org/acme/authz-v3/4093359812...
Processing authorization for fotozibano.ir...
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):
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 unboundtest.com.
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.)
I can confirm that fotozibano.ir 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:
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 https://letsencrypt.org/docs/client-options/. 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:
158.58.190.67
We also turned off the firewall and also used acme.sh, which is introduced in the ACME Client Implementations page, but again we got the same results as before: https://acme-v02.api.letsencrypt.org/acme/chall-v3/4127385809/BfjdTQ
Can you give me some new tips?
Hi
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…
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 webhostingtalk.ir
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.
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.