Add two TXT records for the same subdomain

[sahsanu]

Hello,

Due the upcoming Let's Encrypt wildcard certificates, if we want a certificate covering domain.tld and *.domain.tld we need to create two _acme-challenge.domain.tld TXT records, one for the token of domain.tld and another one for *.domain.tld

_acme-challenge.domain.tld TXT tokenfordomain
_acme-challenge.domain.tld TXT tokenforwildcard

Using acme-dns we only need to create an _acme-challenge.domain.tld CNAME record pointing to our fulldomain aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.auth.whatever.tld but as far as I know, using acme-dns api we can only set 1 TXT record for our subdomain so it shouldn't be possible to issue a cert covering domain.tld and *.domain.tld.

Is there an option/workaround to accomplish this task?. If not, it should be great to add the possibility to add an additional TXT record for a subdomain.

Thank you very much for your work.

Cheers,
sahsanu

[joohoi]

Would the use case here be having two different set of credentials to distribute between host that needs only the domain.tld and a host that needs the *.domain.tld?

If this is not the case, you should be able to use the single ACME-DNS credentials with a single CNAME pointing to the generated subdomain. I think the challenges are solved in sequential manner, and the TXT records do not need to be left there for any longer than the time it takes the CA to actually validate the token. So with single record and credentials the flow would be something along the lines of:

1. Update challenge token for domain.tld
2. CA validates the record
3. Update challenge token for *.domain.tld
4. CA validates the record

For distributing the credentials I think this new feature needs to be implemented. In my opionion this should be implemented as a new parameter for /register endpoint, allowing the user to tell ACME-DNS that this subdomain is dual-homed. In this case two sets of username + password combinations would be created for a single subdomain, and returned to the client.

Tell me what you think!

[sahsanu]

Hi @joohoi,

The use case is having the same credential and issue a certificate that covers both domains, domain.tld and *.domain.tld.

As far as I known, the validation occurs after the tokens are provided, so the txt records must be created before the validation occurs. So, we need to create 2 TXT records before the validation occurs and this is not possible with the current acme-dns implementation.

1. Update challenge token for domain.tld
2. Update challenge token for *.domain.tld
3. CA validates the records

At least this is the case using acme.sh client and I think it will be the same for certbot when it implements v2 api.

[joohoi]

I think that even in ACMEv2 the challenges are individual objects that can be validated separately, so the described behavior is more of an implemented feature of a specific ACME client. That said, the new feature obiviously is needed for this exact reason.

The main reason this project exists is to provide privilege separation for updating the TXT records for ACME DNS challenges. Because of this, I think the only reasonable solution would be to enable the users to provide an optional parameter in the registration step to be able to gain two sets of credentials for a signel subdomain that the CNAME can be pointed to.

[sahsanu]

I will made some more tests using acme.sh and will wait till certbot APIv2 implementation to test it but I'm afraid they will validate the records as they do right now, all at once instead one by one, let's see ;)

[joohoi]

You are absolutely correct. I got confused here for a bit.

How would you feel about the following change in /update endpoint (not creating a new set of credentials like previously proposed):

• Add an optional input data field multiple that takes a boolean value. If this is true, another TXT record gets created (if not existing already), or the older one of the two gets updated if already existing.

The other option to solve this would be to just add two TXT records per default and to always update the older of two.

[joohoi]

Personally, I think I'm leaning a bit towards the second option; rolling update of the older of two default TXT records to avoid added complexity.

[sahsanu]

Hi @joohoi ,

I agree, second option will work and there is no need to modify the current scripts using the API to add new options, parameters or checks.

[sahsanu]

I've been testing the new multi_txt branch and it is working fine, I'll perform more tests next days but seems it works smoothly ;)

Thank you very much.

[joohoi]

Awesome, thanks for the feature request and testing!

I found some issues in the database upgrade functionality on PostgreSQL, but now that they're fixed and everything seems to be working fine I'm going to merge it. Don't hesitate to open a new issue if any kind of reason arises.