Currently if you are requesting *.example.com and example.com in the same cert (which is pretty common, to say the least) the required dns challenge TXT record will be named _acme-challenge.example.com in both cases, requiring a duplicate or multi-value TXT record to be created. This is particularly troublesome for some popular APIs like AWS Route 53, which by default will clear our the last value written.
Could wildcard challenges instead be __acme-challenge.example.com instead (or anything else really)? That would avoid this name collision issue and would allow DNS providers to us Add/Update logic instead of Create followed by an eventual delete in order to keep DNS records organised.
If you invoke the API correctly (UPSERT with all of the RRs you want to keep), it does not wipe records out. The Certbot Route53 plugin is a good reference on how to do it right.
Have you seen other providers that work the same way?
Thanks for the tips folks, much appreciated. Yes @_az, the bug in this case is indeed that the AWS provider requires a change set that includes the existing records, as will some other providers.
@JuergenAuer interesting solution! My client Certify (for windows) does now support multi challenge per cert, because otherwise certs with multiple domains from mixed DNS providers can’t work.
I still maintain that it’s a complication that doesn’t really need to exist, which makes it feel like it was missed in the original design (which would be perfectly understandable).
Remember, DNS plugins are often maintained by third parties besides the primary authors of ACME clients. Your solution would require every ACME client’s DNS plugins to be updated to understand the new DNS label.
Reusing the same DNS label for wildcard certificates makes it unnecessary in many cases to update the various DNS plugins to ACME clients. All a client has to do is add ACMEv2 support to their core, and most of their existing DNS plugins will continue to work.
The only reason you would need to update a DNS plugin if it wasn’t capable of dealing with two records, either by handing it both records or making sure it upserts. This is a much smaller set of DNS plugins to update.
I’m don’t think it’s fair to ask to entire ecosysyem to make sweeping changes to work around the limitations of a few DNS providers. Maybe if Let’s Encrypt were doing something novel or uncommon, but having multiple DNS TXT records for one domain is hardly uncommon.
@Patches thanks, I do agree that DNS providers require a massive amount of work to maintain (although not relevant in this case as it’s the client, not the API provider, who should determine the DNS challenge label prefix).
I was also forgetting that the _acme-challenge part is hard coded into the current ACME spec and not delivered as part of the DNS validation payload, so as you say that would require code changes on the clients.
Perhaps in the future we could have extensions to customise challenge behaviour based on settings in the initial challenge request, for instance http challenges could support a .txt/custom extension (which may fix a subset of http challenge issues when fighting with native webserver content path routing). That could also include a preference on how wildcard challenge records are named.
.