Dns-01 vs. Wildcard certificates

Issuance Policy
1

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?

Thank you,

Julian “haoLink” ^^

2

I'm a little confused ( but that may just be me :wink: )

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.

3

[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.

4

Thanks, I understand better what you were meaning now. Perhaps the thread at "Walking up" for authorization is appropriate.

5

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. _acme-challenge.example.com for example.com).

At least that’s what’s in the latest ACME draft. Things might change. :smile:

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.