I’m OpenResty with Lua script to request certificate on the fly.
I can get certificate for the domain 1777900.com but cannot for domain www.1777900.com
rainflying@rainflying-mac ~/temp % curl -I ‘https://www.1777900.com’
curl: (51) SSL: no alternative certificate subject name matches target host name ‘www.1777900.com’
According to the log message, it seems there was some issue with the DNS resolution.
I tried some online DNS tools, seems there were no issues with the DNS resolution.
Is it possibe there were some issues with the DNS server Let’s encrypt is using ?
Sorry to hear about the trouble you're having getting a certificate.
It looks like its the other way around: your authoritative DNS servers are returning SERVFAIL for queries to resolve www.1777900.com. I was able to reproduce this error using Let's Debug: Let's Debug and it matches what I see in the validation authority logs for this domain.
It looks like you have this subdomain CNAME'd to aicai2web2.dgcnamerecovery.net and the authoritative nameservers for this domain name seem to be having issues serving DNSKEY query responses (among other things): http://dnsviz.net/d/www.1777900.com/dnssec/
You'll have to work with your authoritative DNS server providers to resolve these issues before Let's Encrypt will be able to issue for the domain.
There are other things going wrong with your authoritative DNS beyond answering incorrectly for DNSKEY queries.
I can also observe SERVFAILs for CAA, A and AAAA queries intermittently. The base domain is also affected by these errors, see e.g.: Let's Debug I'd guess that the intermittent aspect of these errors means you were able to pass a validation for the base domain with some good luck.
You don't need DNSSEC support but your nameservers must not return errors when a DNSSEC enabled recursive resolver interrogates them.
I have a question needs to be clarified first. When Let’s Encrypt request the DNS records for some domain, let’s say 1777900.com, does it send the queries to the authoritative DNS servers of 1777900.com ? I tried sending DNS queries to ns1.dns.com through dig for A records, I couldn’t get an IP address. Is this the cause of failure with this domain ?
Another one, how do I know my authoritative DNS servers are responding to dnskey queries correctly ? I saw the link you pasted, but I couldn’t see anything useful. I tried www.google.com, I could see some graphs there.
It’s fine if your authoritative nameservers return a CNAME for a subdomain (e.g. www.1777900.com); Let’s Encrypt will follow it by querying the authoritative nameservers for the domain the CNAME record points to. The problem is if you try to put a CNAME at the apex of the domain (1777900.com), which is invalid - although I don’t actually know if Unbound, the DNS resolver that Let’s Encrypt uses, rejects it.
In any case, you should point 1777900.com at an IP address. You can leave www.1777900.com as a CNAME if you like. I don’t know if this will be enough to solve your problem though.
Some DNS services provide a special type of “record” which is often called an alias record, which is not a real DNS record at all but automatically creates an A (or AAAA) record based on looking up another DNS name, so functionally it behaves similarly to a CNAME but is fine to use on a domain apex. If your DNS provider allows it, this might be a better option for your use case.
CNAME records are fine, but aicai2web2.dgcnamerecovery.net is also a CNAME to itself (which is an invalid configuration). Also, the dgcnamerecovery.net domain seems to have some other DNS configuration troubles.
If you use a CNAME, you’ll have to be sure that the target of the CNAME has a valid DNS configuration that Let’s Encrypt can resolve correctly. However, Let’s Encrypt is willing to follow CNAMEs during the validation process.