Hello LetsEncrypt team,
first of all: thank you for your amazing work. I’m running Let’s Encrypt on several of my domains and it’s working like a charm.
Now as the topic suggests I’m wondering about the wildcard support in the future. I do realise that using the http-01 verification or similar verification methods it would be hard to properly implement a safe wildcard issuing way as all the domains would have to be checked - which in case of a wildcard would simply require an infinit amount of possible domains to be checked.
However, for the dns-01 challenge I imagine wildcard support would be possible.
As of now if my understanding is correct the dns-01 challenge (I haven’t used it yet) requests a TXT record in the format like the following:
_acme-challenge.example.com. 300 IN TXT “gfj9Xq…Rg85nM”
Now I wonder if there are any technical issues in allowing the following:
_acme-wildcard-challenge.example.com. 300 IN TXT “gfj9Xq…Rg85nM”
(notice: my DNS operator - Rage4 - wouldn’t have allowed _acme-challenge.*.example.com. so I assume the * is not allowed in TXT records)
And well, I imagine technical hurdles for such an implementation would be low, but I won’t outrule “legal” issues (as in: the Let’s Encrypt chain might be disapproved by certain browsers).
Is it anything like that?
Julian “haoLink” ^^
I'm a little confused ( but that may just be me )
From a wildcard perspective I don't see any difference between a http challenge and a dns challenge.
You either accept that a single check on the main domain is sufficient evidence to issue a wildcard certificate ( either via http on the main domain, or via dns as you suggest with a single token) or you don't accept it's sufficient evidence. To me the type of check (http or DNS ) makes no difference.
or am I misunderstanding what you are suggesting.
You are correct.
For a subdomain it would be
_acme-challenge.subdomain.example.com. 300 IN TXT "gfj9Xq...Rx7v8S"
note: for each subdomain it requires a different token / challenge in the DNS text file - they are not all the same.
[quote=“serverco, post:2, topic:16372”]
You either accept that a single check on the main domain is sufficient evidence to issue a wildcard certificate ( either via http on the main domain, or via dns as you suggest with a single token) or you don’t accept it’s sufficient evidence. To me the type of check (http or DNS ) makes no difference. [/quote]
In my understanding it would make a bit of a difference. There could be times when you request a certificate for a sub-domain where it could mean that you’re only in control of that particular sub-domain. As in you request a certificate for sub.example.com - as you only have control over that zone or sub-domain on the server you request the certificate from.
Being able to change the DNS entries of a zone and thus add an entry normally suggests that you’re in control of the entire zone - sure there might be child zones but if you are in charge of the parent zone you could always remove the SOA entries for child zones.
Thanks, I understand better what you were meaning now. Perhaps the thread at "Walking up" for authorization is appropriate.
ACME actually makes this a lot simpler:
It is up to the server's local policy to decide which names are
acceptable in a certificate, given the authorizations that the server
associates with the client's account key. A server MAY consider a
client authorized for a wildcard domain if it is authorized for the
underlying domain name (without the "*" label).
So basically, if Let’s Encrypt ever decides to issue wildcard certificates, it would be sufficient to demonstrate control over the underlying domain name (i.e.
At least that’s what’s in the latest ACME draft. Things might change.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.