[Bug] handling DNS challenge alias mode with multiple domains

JeGr

I was testing the acme package with the new 'desec.io' provider and using challenge-alias. For a single domain that worked just fine, letting the CNAME take LE to the dedyn.io domain and look for the TXT entry that the acme package put there.

But: as the acme.sh documentation states for a SAN certificate, if you are using multiple (sub)domains or hostnames, you should omit additional --dns-XY parameters and let acme handle those domains with that same service configured a single time. With the current acme package, that is not possible at all or I don't see how as you can't add additional domains without selecting a method.

The additional problem with selecting the same type again and again is, that your package then adds them ALL to the command line making acme.sh think those domains are to be handled differently by multiple providers, thus forcing a new TXT entry and key for every single domain given. So while that may work well enough with the DNS01 normally, with challenge-alias it gets hit by a brickwall. As you specify an alias domain like aliasforacme.dedyn.io and with multiple --dns-desec parameters equipped, acme.sh creates a new key for every given domain in that job. So if you have 4 SAN entries, every entry submits a TXT record to _acme-challenge.aliasforacme.dedyn.io thus overwriting it every time and only the last entry will stay there for the verification job.

That can escape debugging very simply as with every try you run, LetsEncrypt recognizes domains that are already verified thus domain #4 no longer needs an entry and acme.sh doesn't need to create it. So only 3 entries are run through, it bugs out again with an error for domain #1 and #2 but #3 is now verified too. Try again 3 times and at last, you will have a working domain and wonder, why the heck it didn't work in the first place. Until you renew that domain again - and need 5 days (and cronjobs) until it renews cleanly.

I tested that here:

TestCert
Renewing certificate 
account: staging 
server: letsencrypt-staging-2 

/usr/local/pkg/acme/acme.sh  --issue  --domain 'host.ure.email' --challenge-alias 'jlab.dedyn.io' --dns 'dns_desec'  --domain 'host1.ure.email' --challenge-alias 'jlab.dedyn.io' --dns 'dns_desec'  --domain 'host2.ure.email' --challenge-alias 'jlab.dedyn.io' --dns 'dns_desec'  --domain 'host3.ure.email' --challenge-alias 'jlab.dedyn.io' --dns 'dns_desec'  --home '/tmp/acme/TestCert/' --accountconf '/tmp/acme/TestCert/accountconf.conf' --force --reloadCmd '/tmp/acme/TestCert/reloadcmd.sh' --dnssleep '10' --log-level 3 --log '/tmp/acme/TestCert/acme_issuecert.log'
Array
(
    [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
    [DEDYN_TOKEN] => xxxxx
    [DEDYN_NAME] => xxxxx
)
[Tue Nov  8 13:47:41 CET 2022] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory
[Tue Nov  8 13:47:42 CET 2022] Multi domain='DNS:host.ure.email,DNS:host1.ure.email,DNS:host2.ure.email,DNS:host3.ure.email'
[Tue Nov  8 13:47:42 CET 2022] Getting domain auth token for each domain
[Tue Nov  8 13:47:47 CET 2022] Getting webroot for domain='host.ure.email'
[Tue Nov  8 13:47:47 CET 2022] Getting webroot for domain='host1.ure.email'
[Tue Nov  8 13:47:47 CET 2022] Getting webroot for domain='host2.ure.email'
[Tue Nov  8 13:47:47 CET 2022] Getting webroot for domain='host3.ure.email'
[Tue Nov  8 13:47:47 CET 2022] Adding txt value: fTy_XoimiTxJOQqghzo6VjzeDA4S4hI8rp7ApTmnEKk for domain:  _acme-challenge.jlab.dedyn.io
[Tue Nov  8 13:47:47 CET 2022] Using desec.io api
[Tue Nov  8 13:47:48 CET 2022] Adding record
[Tue Nov  8 13:47:48 CET 2022] Added, OK
[Tue Nov  8 13:47:48 CET 2022] The txt record is added: Success.
[Tue Nov  8 13:47:48 CET 2022] Adding txt value: U0bs51NvKt30edlsm5TLJXB2o2d-2FTfSedgfXDHXnQ for domain:  _acme-challenge.jlab.dedyn.io
[Tue Nov  8 13:47:48 CET 2022] Using desec.io api
[Tue Nov  8 13:47:48 CET 2022] Adding record
[Tue Nov  8 13:47:49 CET 2022] Added, OK
[Tue Nov  8 13:47:49 CET 2022] The txt record is added: Success.
[Tue Nov  8 13:47:49 CET 2022] Sleep 10 seconds for the txt records to take effect
[Tue Nov  8 13:47:59 CET 2022] host.ure.email is already verified, skip dns-01.
[Tue Nov  8 13:47:59 CET 2022] host1.ure.email is already verified, skip dns-01.
[Tue Nov  8 13:47:59 CET 2022] Verifying: host2.ure.email
[Tue Nov  8 13:48:00 CET 2022] Pending, The CA is processing your order, please just wait. (1/30)
[Tue Nov  8 13:48:02 CET 2022] Removing DNS records.
[Tue Nov  8 13:48:02 CET 2022] Removing txt: fTy_XoimiTxJOQqghzo6VjzeDA4S4hI8rp7ApTmnEKk for domain: _acme-challenge.jlab.dedyn.io
[Tue Nov  8 13:48:02 CET 2022] Using desec.io api
[Tue Nov  8 13:48:03 CET 2022] Deleting record
[Tue Nov  8 13:48:03 CET 2022] Deleted, OK
[Tue Nov  8 13:48:03 CET 2022] Removed: Success
[Tue Nov  8 13:48:03 CET 2022] Removing txt: U0bs51NvKt30edlsm5TLJXB2o2d-2FTfSedgfXDHXnQ for domain: _acme-challenge.jlab.dedyn.io
[Tue Nov  8 13:48:03 CET 2022] Using desec.io api
[Tue Nov  8 13:48:02 CET 2022] host2.ure.email:Verify error:Incorrect TXT record 
[Tue Nov  8 13:48:04 CET 2022] invalid domain
[Tue Nov  8 13:48:04 CET 2022] Error removing txt for domain:_acme-challenge.jlab.dedyn.io
[Tue Nov  8 13:48:04 CET 2022] Please check log file for more details: /tmp/acme/TestCert/acme_issuecert.log

I created 5 dummy entries for a nonsense domain with another provider: host[1-4]?.ure.email and configured them to point to jlab.dedyn.io. The log above shows try #3 with host and host1 already succeeded through tries #1 and #2 and in #3 you clearly see that acme.sh hands out 2 different TXT values for the validation that both gets entered into the dedyn API overwriting each other. That may be a problem of dedyn's API (as you could have 2 TXT records in parallel I suppose), but the problem persists, that it shouldn't be done that way. The doc of acme.sh shows that here:
https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode#3-share-the-same-aliased-domain

The command should look like

/usr/local/pkg/acme/acme.sh --issue --domain 'host.ure.email' --challenge-alias 'jlab.dedyn.io' --dns 'dns_desec' --domain 'host1.ure.email' --domain 'host2.ure.email' --domain 'host3.ure.email' --home '/tmp/acme/TestCert/' --accountconf '/tmp/acme/TestCert/accountconf.conf' --force --reloadCmd '/tmp/acme/TestCert/reloadcmd.sh' --dnssleep '10' --log-level 3 --log '/tmp/acme/TestCert/acme_issuecert.log'

to only have the first --domain entry have the DNS type and challenge-alias configured. Perhaps we could simply add another choice to the enabled/disabled dropdown? Like "Alias" and if that is selected instead of "Enabled" then the DNS-method is disabled so you can't accidentally select another entry that way? Wanted to pass that idea by here in the forums before creating a redmine issue too fast about it :)

Cheers
\jens

jimp

That could probably use some work. Right now it's geared toward each entry using a different provider or some different mechanism. It's hard to test all of that though since I really only have RFC2136 to test against and that works great with multiple domains for me, but I also don't use the challenge alias since it isn't necessary for me.

A lot of that code pre-dates my involvement with the package and might be quite a bit of effort to redesign and test to make sure it doesn't break things for others that are working now as-is.

JeGr

@jimp said in [Bug] handling DNS challenge alias mode with multiple domains:

have RFC2136 to test against and that works great with multiple domains for me, but I also don't use the challenge alias since it isn't necessary for me.

No problem I can assist with that if needed anytime :) As i did a bit of work with the folks of desec (see the post about the dyndns implementation in the DHCP section), I have a dyn account there as well as a pretty flexible DNS for a dummy domain where I can create those CNAME redirects. Otherwise I'd be still looking why it suddenly started working (and why it didn't break after adding one domain but broke after two ;))

If I can help any way lemme know. As of now the only workaround I found about that is probably warning the user and advising to use domain-alias instead of challenge-alias and use a different alias for every domain used in the multiSAN cert.

Would it be possible - as another idea for simpler fix - to just add a checkbox for DNS-xyz entries (below the DNS domain alias mode) and add a box with "use previous method" or sth along those lines as an option? So that it will omit adding of the method, token etc. parameters for that entry?

Or as another idea: if you select the same method DNS-xyz and only add details on the first entry and leave the others empty then just add a --domain <domain> parameter for that domain without enforcing to fill out all additional options?

Just to add some thoughts to that :)

Cheers

JeGr

@jimp Or another idea for a quick start: how about a simple field below for additional SANs with the same auth method?

Might be confusing though when to use that or add domains in the list above though. Just thought that could be implemented easier then rework the SAN list.

Cheers

JeGr

@jimp Would it be possible to just create another "method" in the UI that simply disables attaching any sort of additional --dns XY parameters, so only the first one (that has to be defined of course) is taken into account? That would already help so much with multi domain SAN / multi wildcard domains that are used in combination with HAproxy and other services!

I just had to manually comb through various customer installations again today because of API/timeout problems caused by needless tries to authenticate additional SAN domains with their own tokens that wouldn't be needed (as all could be tested by using the same).

Cheers