I don't have access to the client's DNS but they changed the A record about two hours ago: shop.agit-global.com 54.176.144.117
According to mxtoolbox.com and testing from my personal machine, the A record is set up correctly. However, when I run the command to issue the cert, I am running into trouble. I am worried about hitting my 50 weekly attempts.
I have used the command to order certificates for other domains dozens of times and have never had any issues. Usually the command works at first attempt within minutes of the DNS A record being configured. Thanks for the help!!
My domain is:
I ran this command:
cd /usr/local/letsencrypt
./letsencrypt-auto --apache -d shop.agit-global.com
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for shop.agit-global.com
Waiting for verification...
Challenge failed for domain shop.agit-global.com
http-01 challenge for shop.agit-global.com
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: shop.agit-global.com
Type: dns
Detail: During secondary validation: DNS problem: SERVFAIL looking
up A for shop.agit-global.com - the domain's nameservers may be
malfunctioning
My web server is (include version):
AWS EC2
The operating system my web server runs on is (include version):
Ubuntu 18.04.5 LTS
My hosting provider, if applicable, is:
AWS
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):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.8.0
This has been a very common issue lately. I believe it is based on the secondary validation servers being overwhelmed at midnight. Please try changing the time the process runs to a somewhat random time several hours and minutes earlier or later.
Thanks for your help with this! I ended up copying the existing cert over from the old server the site was hosted on which buys me some time to get this sorted.
Meanwhile, I am still unable to request a certificate from Let’s Encrypt due to the same issue. I am by no means a DNS expert and I am wondering if there might be something about this domain’s nameserver which LE doesn’t like.
Thanks so much for helping me figure this out! I really appreciate it.
/usr/bin/certbot --version
certbot 0.27.0
I will pass the DNS Lookup Debug on to the client whose IT department manages their DNS. Is there any additional detail I can provide them with that would explain what they did wrong?
hmm...
For a site name that includes the word "global", their DNS is quite lacking from that perspective.
I don't know if "wrong" is the best adjective in this case.
But it could surely have been designed/made "better" / more resilient (more "global").
Have a look at: DNS Spy report for agit-global.com
I will pass this info on to the client who manages their DNS. Unfortunately this likely means we will have to get a certificate from a different provider. Which is so strange to me because the certificates would issue just fine from LE on the old server. Thanks again for all your effort
The original issue is likely the same secondary validation failures that have been happening all over the place. I mentioned this in my very first post. I have noticed that Let's Debug has been returning strange things quite often lately. My results for dig and Let's Debug have conflicted way too often. Glad your results confirm that @JuergenAuer. I might email the Let's Debug guys just to check. Regional issue?
I don't use letsencrpyt but they are used by a web hosting company that we use. I see the same CAA (when no CAA exists) failures along with A/AAAA failures when in fact the A/AAAA records are there and resolving correctly from everywhere except the letsdebug tool. I can run that tool against different zones hosted on the same DNS that return OK but other zones on the same DNS using the same name servers fail all the checks. Its maddening to say the least that companies rely on your service to generate certificates but have no idea what the problem is when it doesn't work.
So why I am here...can anyone tell me what letsdebug.net is actually doing or looking for? Is it as simple as querying the internet or the NS for any given domain for CAA/A/AAAA records? It would be great if there was an output or detail that gave information and logs as to why it failed.
Thanks for joining and providing valuable intel. I have added your report to our internal topic tracking Let's Debug trouble sightings. I would like your post, but I'm out of likes right now.
