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. crt.sh | 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: www.atd.net
I ran this command: getssl -f www.atd.net
It produced this output:
My web server is (include version): Apache 2.4.6
The operating system my web server runs on is (include version): CentOS 7
My hosting provider, if applicable, is: N/A
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): getssl V2.48
(Note: we are using dns-01 for verification)
So I am aware that the normal answer to this is "your DNS servers are blocked by a firewall". But I can not reproduce that. Specifically:
- I can resolve that domain from my home connection across the Internet just fine
- I tested it using https://unboundtest.com/ and it worked fine
- I ran a test across 100 RIPE Atlas probes and the vast majority were able to resolve the domain fine
I DID test using https://letsdebug.net/ and that failed with the error: DNS problem: query timed out looking up TXT for _acme-challenge.www.atd.net (I got a certificate recently for that domain and so when I run getssl the previous domain authorizations are still valid).
So, obviously there is something blocking one of the queries for the domain atd.net, but I cannot figure out what it is. I have a suspicion that it is something not for atd.net, but something wrong resolving the nameservers for that domain. It is possible for me to file a ticket upstream regarding that, but the FIRST thing they are going to ask me is, "What IP address range are the queries coming from?" I know that Let's Encrypt doesn't guarantee that the IP address range for validation will stay the same, but without knowing what it is now I can't pursue things further with our networking people.
I am perfectly willing to believe we are doing something wrong but I cannot figure out what it would be (this has worked fine for over a year so any issues are recent). In case it comes up I am aware the zone atd.net is DNSSEC signed but there are no DS records in .net for that domain; my understanding is that should not matter for this issue.