I’m having problems with Let’s Encrypt (through the dehydrated client) and the DNS challenge (Knot DNS). It’s an IDNA domain, not sure if it’s related (getting certs seems to work through other non-IDNA domains).
The domain is gfrör.li (or in IDNA: xn–gfrr-7qa.li). Here’s the process:
First, let’s ensure there’s no existing TXT record:
$ dig +short TXT _acme-challenge.xn--gfrr-7qa.li @coredump01.nine.ch
$
Now I’ll start the certificate process. Dehydrated will fetch a challenge from the ACME server, then the hook script will update the local DNS server through nsupdate.
$ /opt/letsencrypt/dehydrated -f config -c
# INFO: Using main config file config
Processing xn--gfrr-7qa.li
+ Checking domain name(s) of existing cert... changed!
+ Domain name(s) are not matching!
+ Names in old certificate: www.xn--gfrr-7qa.li xn--gfrr-7qa.li
+ Configured names: xn--gfrr-7qa.li
+ Forcing renew.
+ Checking expire date of existing cert...
+ Valid till Sep 8 00:21:27 2018 GMT (Less than 30 days). Renewing!
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting challenge for xn--gfrr-7qa.li...
+ [hook] Requesting nsupdate add for xn--gfrr-7qa.li (zone xn--gfrr-7qa.li.)...
(Yes, I dropped the subdomain for debugging purposes.)
Here’s the update log from the DNS server:
Dec 30 01:21:44 coredump01 knotd[1219]: 2018-12-30T01:21:44 info: [xn--gfrr-7qa.li.] DDNS, processing 1 updates
Dec 30 01:21:44 coredump01 knotd[1219]: 2018-12-30T01:21:44 info: [xn--gfrr-7qa.li.] DDNS, update finished, serial 2018122923 -> 2018122924, 0.01 seconds
Dec 30 01:21:44 coredump01 knotd[1219]: 2018-12-30T01:21:44 info: [xn--gfrr-7qa.li.] zone file updated, serial 2018122923 -> 2018122924
Then the verification fails:
+ Responding to challenge for xn--gfrr-7qa.li...
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "dns-01",
"status": "invalid",
"error": {
"type": "urn:acme:error:dns",
"detail": "DNS problem: SERVFAIL looking up TXT for _acme-challenge.xn--gfrr-7qa.li",
"status": 400
},
"uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/XXX",
"token": "TIrDR5Abio3mwrjzBM5Zg3fYD3QPrafFNQ95iSTg-4o"
})
As you can see, the validation failed with SERVFAIL looking up TXT for _acme-challenge.xn--gfrr-7qa.li. I’ve commented out the code that would delete the entry again after verification, so the DNS record is still there if you want to verify it. Here’s the dig call from my local machine:
$ dig TXT _acme-challenge.xn--gfrr-7qa.li @coredump01.nine.ch
; <<>> DiG 9.13.4 <<>> TXT _acme-challenge.xn--gfrr-7qa.li @coredump01.nine.ch
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63977
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.gfrör.li. IN TXT
;; ANSWER SECTION:
_acme-challenge.gfrör.li. 60 IN TXT "D64dQUjUrgV_3dGzZXruvYFvM_JoVA_aevy4e8HDU3s"
;; Query time: 78 msec
;; SERVER: 94.230.210.84#53(94.230.210.84)
;; WHEN: Sun Dec 30 01:25:22 CET 2018
;; MSG SIZE rcvd: 116
I have debugged this for hours now and simply cannot figure out why ACME servers cannot validate this entry. Note: This process used to work beginning of 2018, but stopped working sometime in Q3 or Q2. This could be a DNS server update or something like that, maybe there’s an incompatibility?
I’d be happy about any help.
Note: I tried to set up DNSSEC a while ago, but failed so far, so I removed all related config in the DNS server again. It seems that some things survived though: https://dnssec-debugger.verisignlabs.com/xn--gfrr-7qa.li Could this be the problem? If yes, it would be really really really helpful if the error message would say so.
(Although a custom protocol or a DNS resolver library would allow for detailed error analysis, like the letsdebug site does it.)
)