I am attempting to setup on Caddy on Windows. When attempting to request certificates for the first time i receive the error below.
ctivating privacy features… 2018/12/04 15:55:58 [FQDN] failed to get certificate: acme: Error 400 - urn:ietf:params:acme:error:dns - DNS problem: query timed out looking up CAA for FQDN
Here is what the CAA record is for the domain in question.
When using a caddyfile without https the configuration works as expected. What additional troubleshooting can be performed to resolve the CAA lookup issue?
Just looking at the response that I’m recieving, and my caddyfile, the error I’m getting states that no CAA can be found for the address in question (subdomain.domain.com) which is correct as the CAA record is associated with just domain.com.
Should my opening line just include the domain only with the actual site I’m looking to run through Caddy be reference elsewhere?
CAA records set on a bare domain are inherited by their subdomains unless the subdomain presents a different CAA record.
The errors above don’t indicate there is no CAA record; they indicate that the nameserver LetsEncrypt tried to contact to retrieve the CAA record did not respond to them. Are you getting new errors since? If LetsEncrypt gets an authoritative response indicating no CAA record, it should happily issue the certificate.
I’m not 100% sure what the latter half of the sentence is asking for. The first line of your Caddyfile should always be the site you want to serve - the address you want people typing in their browser. Is this separate from the “actual site” you’re serving? Are you proxing to a different site maybe?
Your name server shouldn’t be returning errors for a lookup to a subdomain for CAA records. It is valid to supply subdomain-specific CAA records.
That said, the DNS server will not return results for the bare domain for a request for the subdomain. It’s a specification of the CAA resource record that the apex record applies to subordinate domains, not a specification of the DNS system itself; a system that issues certificates (like LetsEncrypt) should check the apex record if the subdomain does not have any records.
The following example is a DNS zone file (see [RFC1035]) that informs CAs that certificates are not to be issued except by the holder of the domain name ‘ca.example.net’ or an authorized agent thereof. This policy applies to all subordinate domains under example.com.
Bear in mind that 1.1.1.1 is not authoritative for your domain, those would be:
Name Server: NS10.DNSMADEEASY.COM
Name Server: NS11.DNSMADEEASY.COM
Name Server: NS12.DNSMADEEASY.COM
Name Server: NS13.DNSMADEEASY.COM
Name Server: NS14.DNSMADEEASY.COM
Name Server: NS15.DNSMADEEASY.COM
Name Server: DNS1.EASYDNS.COM
Name Server: DNS2.EASYDNS.NET
Name Server: DNS3.EASYDNS.ORG
Name Server: DNS4.EASYDNS.INFO
LetsEncrypt will be querying the above.
whitestrake at apollo in ~
❯ dig @NS10.DNSMADEEASY.COM culvers.com CAA
; <<>> DiG 9.10.6 <<>> @NS10.DNSMADEEASY.COM culvers.com CAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27877
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;culvers.com. IN CAA
;; ANSWER SECTION:
culvers.com. 1800 IN CAA 0 issuewild "letsencrypt.org"
culvers.com. 1800 IN CAA 0 issue "letsencrypt.org"
culvers.com. 1800 IN CAA 0 issuewild "godaddy.com"
culvers.com. 1800 IN CAA 0 issue "godaddy.com"
;; AUTHORITY SECTION:
culvers.com. 86400 IN NS ns13.dnsmadeeasy.com.
culvers.com. 86400 IN NS ns11.dnsmadeeasy.com.
culvers.com. 86400 IN NS ns10.dnsmadeeasy.com.
culvers.com. 86400 IN NS ns12.dnsmadeeasy.com.
;; Query time: 49 msec
;; SERVER: 208.94.148.4#53(208.94.148.4)
;; WHEN: Tue Dec 11 10:17:15 AEST 2018
;; MSG SIZE rcvd: 264
Looks good. As for the subdomain:
whitestrake at apollo in ~
❯ dig @NS10.DNSMADEEASY.COM hvac-ctrl-01.culvers.com CAA
; <<>> DiG 9.10.6 <<>> @NS10.DNSMADEEASY.COM hvac-ctrl-01.culvers.com CAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33162
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;hvac-ctrl-01.culvers.com. IN CAA
;; AUTHORITY SECTION:
hvac-ctrl-01.culvers.com. 900 IN NS vdns1.culvers.com.
hvac-ctrl-01.culvers.com. 900 IN NS vdns2.culvers.com.
;; ADDITIONAL SECTION:
vdns1.culvers.com. 900 IN A 71.13.132.242
vdns2.culvers.com. 900 IN A 216.250.6.244
;; Query time: 50 msec
;; SERVER: 208.94.148.4#53(208.94.148.4)
;; WHEN: Tue Dec 11 10:21:33 AEST 2018
;; MSG SIZE rcvd: 125
Exactly as expected.
I assume that 1.1.1.1 is returning SERVFAIL because it is not authoritative and the authoritative server did not return any CAA records, so it’s telling you it doesn’t have anything for you (but it can’t be 100% sure).
Alternatively, the recursive resolver at 1.1.1.1 wasn’t able to successfully query your name server for CAA records at the subdomain at all. That would imply some issue on Cloudflare’s end. It shouldn’t be important; your actual authoritative name server is returning the expected result, and that’s what LetsEncrypt will check.