# DNS-Label for wildcard-certificate-validation **URL:** \ **Category:** Issuance Policy\ **Created:** [January 14, 2018, 2:25pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415 "2018-01-14T14:25:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 14, 2018, 2:25pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/1 "2018-01-14T14:25:42Z")
Hallo, I wonder why the DNS-Label for the wildcard-certificate-validation is the same as for non-wildcard. If a server for [example.com](http://example.com) is running by a third party, I gave them the ability to set the txt-record for \_acme-challenge.example.com to get a certificate for [example.com](http://example.com) only. But with the start of wildcard-certificates, they are able to get a certificate for \*.example.com which is not acceptable. How can I control, who can issue wildcard-certificates? CAA doesn’t help, because I don’t want to deny a certificate for \*.example.com (want to get it for another server). Wouldn’t it be better, if wildcard-certificate-validation uses another dns-record, for example \_acme-challenge.\_wildcard.example.com? tob\_ ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [January 14, 2018, 2:44pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/2 "2018-01-14T14:44:57Z")
If the server for [example.com](http://example.com) is runned by a 3rd party, wouldn’t they also be able to manage to get the `_acme-challenge._wildcard.example.com`? ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 14, 2018, 3:28pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/3 "2018-01-14T15:28:42Z")
They manage the server, which [example.com](http://example.com) A-Record points to. They do not control the dns-server. I gave them control over \_acme-challenge.example.com-TXT-record only. ---
**Author:** ![serverco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/serverco/32/4251_2.png) [@serverco](https://community.letsencrypt.org/u/serverco)\ **Post date:** [January 14, 2018, 4:02pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/4 "2018-01-14T16:02:09Z")
wildcard certificates can only be issued on DNS verification ( from the spec), not by http-01 verification. So if they don’t have DNS control, then they can’t obtain a wildcard certificate. ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 14, 2018, 4:06pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/5 "2018-01-14T16:06:10Z")
I gave them control over the record needed for dns-validation. Unfortunately it’s the same record for wildcard and non-wildcard. When http-validation is not possible, then I have no chance to allow them non-wildcard only. ---
**Author:** ![FGasper](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/fgasper/32/18787_2.png) [@FGasper](https://community.letsencrypt.org/u/FGasper)\ **Post date:** [January 14, 2018, 4:50pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/6 "2018-01-14T16:50:39Z")
Are you saying that you gave someone access to update `_acme-challenge.example.com` but not to create new records? Personally, having looked now at the wildcard validation, I’m a bit surprised that there’s not a randomizer in the DNS record for wildcard; e.g., to verify control over any and all DNS records for `example.com` you’d have to create \_acme-challenge-wildcard-$[token.example.com](http://token.example.com). ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 14, 2018, 5:22pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/7 "2018-01-14T17:22:33Z")
> [@FGasper](#): > > Are you saying that you gave someone access to update \_acme-challenge.example.com but not to create new records? Yes. Create, update and delete only this record as type txt, but no other records. ---
**Author:** ![FGasper](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/fgasper/32/18787_2.png) [@FGasper](https://community.letsencrypt.org/u/FGasper)\ **Post date:** [January 14, 2018, 11:26pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/8 "2018-01-14T23:26:23Z")
Yeah, I agree: wildcard should require creation of a random record, not just setting one that likely already exists. (@cpu?) ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [January 14, 2018, 11:56pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/9 "2018-01-14T23:56:25Z")
> [@tob](#): > > When http-validation is not possible, then I have no chance to allow them non-wildcard only. ~~@tob you can prevent issuance of wildcards with the following CAA configuration:~~ ```nohighlight domain.example. 300 IN CAA 0 issuewild "\;" domain.example. 300 IN CAA 0 issue "letsencrypt.org" ``` ~~I tested this out:~~ ```nohighlight $ acme.sh --renew -d 'tld.example' -d '*.tld.example' --dns --force --log --staging [Mon 15 Jan 10:53:50 AEDT 2018] Using stage ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory [Mon 15 Jan 10:53:50 AEDT 2018] Renew: 'tld.example' [Mon 15 Jan 10:53:51 AEDT 2018] Multi domain='DNS:tld.example,DNS:*.tld.example' [Mon 15 Jan 10:53:51 AEDT 2018] Getting domain auth token for each domain [Mon 15 Jan 10:53:51 AEDT 2018] Verifying:tld.example [Mon 15 Jan 10:53:55 AEDT 2018] Success [Mon 15 Jan 10:53:55 AEDT 2018] Verifying:*.tld.example [Mon 15 Jan 10:53:58 AEDT 2018] *.tld.example:Verify error:CAA record for *.tld.example prevents issuance [Mon 15 Jan 10:53:58 AEDT 2018] Please check log file for more details: /home/example/.acme.sh/acme.sh.log [Mon 15 Jan 10:54:00 AEDT 2018] The dns manual mode can not renew automatically, you must issue it again manually. You'd better use the other modes instead. ``` edit: Sorry, didn't read carefully. Perhaps once CAA `account-uri` is implemented it will be more helpful for you. ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 15, 2018, 9:09am UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/10 "2018-01-15T09:09:57Z")
> [@tob](#): > > CAA doesn’t help, because I don’t want to deny a certificate for \*.example.com (want to get it for another server). > [@\_az](#): > > @tob you can prevent issuance of wildcards with the following CAA configuration: I don't want to prevent issuance - I want to control which system is allowed to issue which certificates. This is why I use dns-validation, it is the most secure validation (secured by DNSSEC), and I have full control, every system has write access to the minumum of dns-records that are needed. By using the same dns-label for wildcard- and non-wildcard-validation this control get lost with no understandable reason. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [January 15, 2018, 2:26pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/11 "2018-01-15T14:26:55Z")
> [@FGasper](#): > > Yeah, I agree: wildcard should require creation of a random record, not just setting one that likely already exists. (@cpu?) The randomness is in the TXT value. Why should there be randomness in the label? An existing DNS-01 TXT record will not satisfy a new DNS-01 issuance for a wildcard name, the value will not match. > [@tob](#): > > If a server for [example.com](http://example.com) is running by a third party, I gave them the ability to set the txt-record for \_acme-challenge.example.com to get a certificate for [example.com](http://example.com) only. But with the start of wildcard-certificates, they are able to get a certificate for \*.example.com which is not acceptable. > > How can I control, who can issue wildcard-certificates? CAA doesn’t help, because I don’t want to deny a certificate for \*.example.com (want to get it for another server). I agree this particular scenario (delegated TXT access, forbidding wildcard issuance to just that delegated party, while allowing wildcard issuance for another party) doesn't meld nicely with our wildcard issuance plans. I don't believe this is a particularly common scenario. I agree with @_az's that there is functionality in [GitHub - ietf-wg-acme/acme-caa: CAA extensions for ACME-based CAs](https://github.com/ietf-wg-acme/acme-caa) that will eventually help address this scenario as well. I'm hopeful we can support the `account-uri` in the near future. ---
**Author:** ![jared.m](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jared.m/32/17871_2.png) [@jared.m](https://community.letsencrypt.org/u/jared.m)\ **Post date:** [January 15, 2018, 6:41pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/12 "2018-01-15T18:41:09Z")
> [@cpu](#): > > The randomness is in the TXT value. Why should there be randomness in the label? An existing DNS-01 TXT record will not satisfy a new DNS-01 issuance for a wildcard name, the value will not match. I would imagine for similar reasons as to why the http-01 challenge file gets a unique name every time, in addition to unique contents. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [January 15, 2018, 6:43pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/13 "2018-01-15T18:43:12Z")
I think the question of tob is valid. If you previously allowed Domain Validation via dns the same Challenge (\_acme-challenge.example.com) which is currently the challenge for an single domain. In future it is valid for Domain and or Wildcard and for what this challenge is depends on the response. There is another scenario There is an PR agency that should host the TLD and should be able to issue an [example.com](http://example.com) certificate and get restricted dns access like tob described it. And the domain owner need an wildcard cert for mail/smtp/pop3 and many more subdomains. Than these to different certificate request will en in the same challenge that will expect different responses. And this will cause one to fail ☹ I think this should be corrected. Also i think it should be considered to use DANE TLSA Record to avaid dns updates that can cause delays with secondary dns servers. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 15, 2018, 6:59pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/14 "2018-01-15T18:59:46Z")
> [@tlussnig](#): > > And the domain owner need an wildcard cert for mail/smtp/pop3 and many more subdomains. Than these to different certificate request will en in the same challenge that will expect different responses. That's not _necessarily_ a problem. It's okay to run two validation simultaneously, as long as both clients update the same TXT record at the same DNS provider and don't erase each other's records. That can be a tall order, though. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [January 15, 2018, 7:04pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/15 "2018-01-15T19:04:11Z")
So this mean that it is ok for boulder if there are two different TXT record answers and the implementation check if there is “at least” one of it valid? Not sure if many DNS-API’s allow to change modify and delete record based on name and content. I think this can cause problems. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [January 15, 2018, 7:05pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/16 "2018-01-15T19:05:54Z")
> [@tlussnig](#): > > So this mean that it is ok for boulder if there are two different TXT record answers and the implementation check if there is “at least” one of it valid? Yes. > [@tlussnig](#): > > Not sure if many DNS-API’s allow to change modify and delete record based on name and content. I think this can cause problems. Yeah. 🙁 Of the two DNS providers I use, one makes it super easy, and one makes it a total pain, but both do support it. ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 16, 2018, 8:52am UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/17 "2018-01-16T08:52:56Z")
> [@cpu](#): > > I agree this particular scenario (delegated TXT access, forbidding wildcard issuance to just that delegated party, while allowing wildcard issuance for another party) doesn’t meld nicely with our wildcard issuance plans. I don’t believe this is a particularly common scenario. I don't think so. A very common hint in this forum is "use dns-validation" if http-validation is not possible or to complicated. And if it is not possible or wanted to open the complete dns-zone with one single api-key another very common hint is -\> use cname to another zone. Thats the same like the scenario above. Only one or two \_acme-challenge-DNS-Records point via cname to a writable location. Some months ago no one could imagine, that the delegation of \_acme-challenge.example.com could lead to a situation, where \_acme-challenge.example.com can be used to get a certificate for [foo.example.com](http://foo.example.com) or [bar.example.com](http://bar.example.com). But now it's even worse - it can be used to get \*.example.com. Domain-owner doesn't even know about this change. Wildcard-certificates are very dangerous, they could compromise security for many services - but why give the server of [example.com](http://example.com) more rights than necessary? Even if the server is not running by a third party - i dont want to give a single service such powerful rights. One single compromised server can compromise the security of other services if this server can get wildcard-certificates - domain-owner has no chance to prevent this. But whats the advantage of using \_acme-challenge.example.com for both [example.com](http://example.com) and \*.example.com? It is even validated twice for a single certificate for [example.com](http://example.com) and \*.example.com. If the user wants to validate both names with the same dns-name - it is possible to cname them to the same dns-name. But if the user want them to be separate (to delegate them to different entities, or to separate privileges) there is no chance. This decision lowers the security (wildcard-certificates should be protected best, because they are very dangerous) at no benefit. > [@cpu](#): > > I agree with @_az’s that there is functionality in [GitHub - ietf-wg-acme/acme-caa: CAA extensions for ACME-based CAs](https://github.com/ietf-wg-acme/acme-caa) that will eventually help address this scenario as well. I’m hopeful we can support the account-uri in the near future. That's no solution for this problem. Not everyone is able to use caa-records: > [@TLS-SNI via CAA](https://community.letsencrypt.org/t/tls-sni-via-caa/50172/11): > > In particular, many DNS providers still don’t allow setting of CAA records, which limits the number of people who could use this option. The idea in this thread was to opt-in via CAA. Your idea is to opt-out to prevent issuance - thats even worse because the limited number of users. The solution is to use a new, different dns-label for wildcard-certificates. That would solve all this problems very easily with no downside with no effect to running installations. CA should not weaken security without explicit opt-in. ---
**Author:** ![riking](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/riking/32/92126_2.png) [@riking](https://community.letsencrypt.org/u/riking)\ **Post date:** [January 16, 2018, 11:01am UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/18 "2018-01-16T11:01:44Z")
> [@tob](#): > > Some months ago no one could imagine, that the delegation of \_acme-challenge.example.com could lead to a situation, where \_acme-challenge.example.com can be used to get a certificate for [foo.example.com](http://foo.example.com) or [bar.example.com](http://bar.example.com). I don't agree with the "no one could imagine" wording, but that might just be a tiny nit. The BRs consider an authorization for a domain to be an authorization for all its subdomains through the concept of an "Authorization Domain Name"; Let's Encrypt took a stricter policy which is what you're relying on. I think the only reasonable solution here is to have your third-party website provider do the http-01 validation - after all, _this exact scenario_ is why http-01 validations are not considered authorizing for subdomains. ---
**Author:** ![tob](https://avatars.discourse-cdn.com/v4/letter/t/a88e57/32.png) [@tob](https://community.letsencrypt.org/u/tob)\ **Post date:** [January 16, 2018, 1:45pm UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/19 "2018-01-16T13:45:37Z")
> [@riking](#): > > Let’s Encrypt took a stricter policy which is what you’re relying on. And this policy will be relaxed without good reason. It will be relaxed especially for wildcard-certificates. Not for normal certificates. > [@riking](#): > > I think the only reasonable solution here is to have your third-party website provider do the http-01 validation - after all, this exact scenario is why http-01 validations are not considered authorizing for subdomains. http-01-validations are less secure than dns-01 with dnssec, and there are other reasons why http-01 is not possible. ---
**Author:** ![Wulf4096](https://avatars.discourse-cdn.com/v4/letter/w/6a8cbe/32.png) [@Wulf4096](https://community.letsencrypt.org/u/Wulf4096)\ **Post date:** [January 22, 2018, 8:08am UTC](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415/20 "2018-01-22T08:08:36Z")
I agree with @tob here. Having different DNS names for the domain itself and wildcards would be better. Not everyone will be aware of the security implications when they allow their webserver access to this one DNS record. And not everyone would be willing to use CAA. “Secure” should be the default. But the default is to not use CAA, thus the wildcard certs feature makes the default insecure. Should the discussion be moved to the mailing list? [https://www.ietf.org/mailman/listinfo/acme](https://www.ietf.org/mailman/listinfo/acme) [Next page](https://community.letsencrypt.org/t/dns-label-for-wildcard-certificate-validation/50415.md?page=2)