Failed to get certificate fo subdomain but ok for the root domain


#1

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://1777900.com
HTTP/1.1 200 OK
Server: openresty/1.13.6.2
Date: Tue, 16 Oct 2018 13:22:09 GMT
Content-Type: text/html
Connection: keep-alive
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 5.1.5

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 ?


#2

Hi @kosunadm,

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: https://letsdebug.net/www.1777900.com/6740 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.


#3

Hi

I have CNAME’ed both www.1777900.com and 1777900.com to aicai2web2.dgcnamerecovery.net. I didn’t enable DNSSEC for domain 1777900.com. In fact, most of the DNS service providers in China doesn’t offer DNSSEC support. If there was some issue with DNSKEY query response, both 1777900.com and www.1777900.com should be affected ?


#4

Hi @kosunadm,

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.: https://letsdebug.net/1777900.com/6747 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.


#5

Hi

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 ?

dig @ns1.dns.com 1777900.com

; <<>> DiG 9.10.6 <<>> @ns1.dns.com 1777900.com
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53175
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; WARNING: Message has 11 extra bytes at end

;; QUESTION SECTION:
;1777900.com. IN A

;; ANSWER SECTION:
1777900.com. 600 IN CNAME aicai2web2.dgcnamerecovery.net.

;; AUTHORITY SECTION:
1777900.com. 28800 IN NS ns1.dns.com.
1777900.com. 28800 IN NS ns2.dns.com.

;; Query time: 195 msec
;; SERVER: 218.98.111.206#53(218.98.111.206)
;; WHEN: Tue Oct 16 22:41:04 CST 2018
;; MSG SIZE rcvd: 134

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.


#6

I don’t know if this is the cause of your problem but a CNAME record at the domain apex is not a valid configuration.

Yes, it does.


#7

Hi jmorahan,

I see. I guess I know what the cause of failure is now.

www.1777900.com is a record pointing to aicai2web2.dgcnamerecovery.net.
Domain 1777900.com is managed by dns.com, but dgcnamerecovery.net is managed by cloudxns.net.
The authoritative DNS servers of 1777900.com have no idea what aicai2web2.dgcnamerecovery.net is resovled to. For this issue, I guess I should resolve 1777900.com and www.1777900.com to an IP address instead of CNAME record, or is it possible for Let’s Encrypt servers to send the queries to some public DNS servers for example Google DNS servers ?


#8

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.


#9

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.


#10

Are you still having issues? A certificate for www.1777900.com was issued a couple hours after your first post, and https://1777900.com/ and https://www.1777900.com/ both work for me right now.

What DNS errors were in your logs?