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


I’m OpenResty with Lua script to request certificate on the fly.
I can get certificate for the domain but cannot for domain

rainflying@rainflying-mac ~/temp % curl -I ‘
HTTP/1.1 200 OK
Server: openresty/
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 ‘
curl: (51) SSL: no alternative certificate subject name matches target host name ‘

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 ?


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 I was able to reproduce this error using 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 and the authoritative nameservers for this domain name seem to be having issues serving DNSKEY query responses (among other things):

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.



I have CNAME’ed both and to I didn’t enable DNSSEC for domain 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 and should be affected ?


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.: 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, does it send the queries to the authoritative DNS servers of ? I tried sending DNS queries to through dig for A records, I couldn’t get an IP address. Is this the cause of failure with this domain ?


; <<>> DiG 9.10.6 <<>>
; (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

; IN A



;; Query time: 195 msec
;; 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, I could see some graphs there.


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.


Hi jmorahan,

I see. I guess I know what the cause of failure is now. is a record pointing to
Domain is managed by, but is managed by
The authoritative DNS servers of have no idea what is resovled to. For this issue, I guess I should resolve and 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 ?


It’s fine if your authoritative nameservers return a CNAME for a subdomain (e.g.; 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 (, 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 at an IP address. You can leave 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 is also a CNAME to itself (which is an invalid configuration). Also, the 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.


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

What DNS errors were in your logs?


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.