I wonder why the DNS-Label for the wildcard-certificate-validation is the same as for non-wildcard.
If a server for 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 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?
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.
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.
@tob you can prevent issuance of wildcards with the following CAA configuration:
domain.example. 300 IN CAA 0 issuewild "\;"
domain.example. 300 IN CAA 0 issue "letsencrypt.org"
I tested this out:
$ 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.
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.
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 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 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 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.
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.
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.
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 or 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 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 and *.example.com? It is even validated twice for a single certificate for 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.
That’s no solution for this problem. Not everyone is able to use caa-records:
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.
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.
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.