Please fix the wildcard DNS validation requirements

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: wb6vpm.duckdns.org

I ran this command: (using certify the web for a wildcard certificate)

It produced this output: requesting multiple DNS TXT entries, one for the root domain (wb6vpm.duckdns.org) and another for the wildcard (*.wb6vpm.duckdns.org)

My web server is (include version): IIS 10

The operating system my web server runs on is (include version): Windows 10 Pro

My hosting provider, if applicable, is: none

I can login to a root shell on my machine (yes or no, or I don’t know): Windows device, I have admin privileges

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certify the web 4.1.6.0

There is no reason I can see to require validation of both the root and the wildcard as separate DNS entries, or if at least nothing else, set them to the same record, as my DNS host responds with the same TXT record for all subdomains (including root)

1 Like

It’s because each object on the SAN of the certificate is processed as a separate validation, this is to ensure every request is legitimate and authorized by the domain operator.

For instance if I operated a domain and provided someone with access to all subdomains but not the root, I wouldn’t want them to be able to obtain certificates for the root with a challenge that should only be valid for all third level domains.

2 Likes

This is a defect with DuckDNS.

Asking Let’s Encrypt to change its behavior to accommodate DuckDNS would be the tail wagging the dog.

It doesn’t work in the unique case of DuckDNS because they have chosen a very peculiar, non-standard concept about how DNS hosting works.

The problem that occurs is that the popular ACME clients tend to parallelize their challenge solvers: they create the TXT records, submit them as a batch to the ACME server, and then clean them all up.

This is a reasonable design because it is faster to quickly create all the records and wait for a single nameserver update at the end. Conversely, if you want to respond to one challenge at a time (as DuckDNS requires), you need to wait for N nameserver updates. Much, much slower, since the nameserver update is generally by far the slowest part of the process.

Luckily for you, lego is an ACME client which was designed in a thoughtful way where the implementation of any DNS provider can either respond to every challenges in one batch, or one by one. This makes it one of the few (maybe the only?) ACME client that supports DuckDNS with multiple domains:

export DUCKDNS_TOKEN=xxx
lego -a -m 'me@example.com' --dns duckdns \
-d example.duckdns.org -d "*.example.duckdns.org" run
5 Likes

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