mirror of
https://github.com/acme-dns/acme-dns.git
synced 2026-04-27 12:55:48 +03:00
[GH-ISSUE #28] Add two TXT records for the same subdomain #7
Labels
No labels
Documentation
Documentation
bug
enhancement
feature request
feature request
help wanted
pull-request
question
security
security
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/acme-dns#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sahsanu on GitHub (Jan 14, 2018).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/28
Hello,
Due the upcoming Let's Encrypt wildcard certificates, if we want a certificate covering
domain.tldand*.domain.tldwe need to create two_acme-challenge.domain.tldTXT records, one for the token ofdomain.tldand another one for*.domain.tldUsing acme-dns we only need to create an
_acme-challenge.domain.tldCNAME record pointing to our fulldomainaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee.auth.whatever.tldbut 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 coveringdomain.tldand*.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 commented on GitHub (Jan 15, 2018):
Would the use case here be having two different set of credentials to distribute between host that needs only the
domain.tldand 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:
domain.tld*.domain.tldFor distributing the credentials I think this new feature needs to be implemented. In my opionion this should be implemented as a new parameter for
/registerendpoint, 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 commented on GitHub (Jan 15, 2018):
Hi @joohoi,
The use case is having the same credential and issue a certificate that covers both domains,
domain.tldand*.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.
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 commented on GitHub (Jan 15, 2018):
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 commented on GitHub (Jan 16, 2018):
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 commented on GitHub (Jan 20, 2018):
You are absolutely correct. I got confused here for a bit.
How would you feel about the following change in
/updateendpoint (not creating a new set of credentials like previously proposed):multiplethat 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 commented on GitHub (Jan 20, 2018):
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 commented on GitHub (Jan 20, 2018):
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 commented on GitHub (Jan 20, 2018):
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 commented on GitHub (Jan 22, 2018):
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.