Hello! I’d like to get some feedback on next steps for a challenge I’ve run into when trying to get wildcard certs, which require the DNS-01 challenge type. The way this challenge is designed, it currently requires proving you have ownership over the specific domain by updating your DNS to include _acme-challenge.<domain-name> as a TXT record. But this is not scalable for services that would like to automate certificates for every subdomain in a given zone.
For example, take a hypothetical service which hosts content for users at example.com. It can easily get a wildcard cert for *.example.com that covers all users of that service. But to allow users to put other content at *.<user>.example.com, we’d have to add a TXT record at the user’s subdomain, and do this for every user on the service (e.g. _acme-challenge.<user>.example.com. This will quickly run into some limitations at scale:
The number of records a given DNS Zone allows
API rate limits for the amount of DNS updates that would be needed when you have to continuously renew these certificates for every user of your service in that zone.
When a provider controls an entire DNS zone with a wildcard DNS record, I wonder if it would be possible to relax this challenge to allow wildcard certs to be issued for any subdomain in that zone. With a wildcard DNS entry, a.b.c.d.e.example.com will always resolve to the same servers as user.example.com, so it seems like it should be reasonably secure to get a certificate for any subdomain in that zone without having to add separate records for each.
Thoughts on this problem? Are there workaround for this maybe I’m missing? Happy to discuss in a more formal RFC/proposal if that’s what’s needed here. Thanks for your time!
If this is a user content domain, you might consider doing a permanent delegation to something like an acme-dns instance, to take your DNS provider out of the loop entirely.
To give some feedback on your proposal, there has been a similar proposal rejected in the past.
When requesting a certificate for example.com + *.example.com, two authorizations are created for an identical authorizing domain name: _acme-challenge.example.com.
The proposal was to combine them into one, since the proof of control is essentially identical.
Your proposal is a lot riskier … don’t really see it happening. But check out acme-dns, it might help your integration concerns.
Q1: Can your "example.com" domain be considered a public TLD?
If so, there are ways to greatly increase the "limits".
Q2. Will all users be issuing wildcard certs?
If not, then those that won't can use the same (single) wildcard cert for that zone to cover their individual names.
S1: Can you make a DNS (sub)zone such that all users are within that same subdomain?
if so, it might help to "merge" all the requests into one single zone [not sure if this will help you out].
So that the required TXT records for *.subdomain.example.com (to cover <(all)user(s)>.subdomain.example.com) can be CNAMEd to "some.other.unique.zone.example.com".
Note:
This is not a restriction imposed by LE - it comes from the CAB forum (which regulates all CAs).
EDIT: found nothing to backup that statement
Yeh it is on the public TLD. I think we'd be ok with the LE rate limits. It's the rate limits for DNS providers I'm more concerned about, especially once we have enough users over time that we're renewing hundreds or thousands of wildcard certs every day.
Good to know, thanks! That's my main question in all this. Whether or not it's a limitation that the community could push to relax when you can prove that you own an entire zone. If it's a use case that's been explicitly disallowed, then I'm definitely going to look more closely into solutions like acme-dns or DNS providers that can handle the churn.
Yeh I've got a PoC where something similar to this is the solution. It would definitely work. Just exploring whether or not it's the best solution.
As for DNS limitations, you can always CNAME to a completely different domain.
One that can handle the load.
[like maybe one that you run yourself - just for this purpose]
Putting usernames in certificates seems fragile. While getting a certificate usually takes seconds, it could take days, so you are creating a hard dependency on Let's Encrypt availability in your create user workflow.
Certificates are also public information and are logged forever in CT, so you might not be able to put usernames in certificates for data privacy reasons.
I don't think so. The BRs allows using example.com as the Authorization Domain Name for *.<user>.example.com
Hello! I’d like to get some feedback on next steps for a challenge I’ve run into when trying to get wildcard certs, which require the DNS-01 challenge type. The way this challenge is designed, it currently requires proving you have ownership over the specific domain by updating your DNS to include