So, I've got a "theory" question rather than a "how-to" question.
I have a vendor who wants to issue certificates for a web-server/web-service they'll offer us.
They're wanting to use a DNS challenge vs the http challenge. (I'm not sure why, and yes, I don't see any good reason for this either - but lets ignore that for now.)
They'll have us create CNAME points for the challenge records in DNS - that point to their DNS infrastructure.
The crux of the question is;
For DNS challenges, it sure appears that they can issue a certificate for ANY subdomain or root or even a wild-card record. There's no way to limit the scope of a DNS challenge, if we point the challenge domain at their DNS.
Is that right?
The HTTP challenge does limit scope, as you can only get a certificate for whatever FQDN's are actually pointed at the HTTP server. (Again, correct me if I'm wrong.)
So, giving this privilege (DNS challenge) is vastly more "dangerous," correct?
I'm glad to be pointed at a document that explains this, but I've read most of the material and I don't find a clear answer to this specific question - so if you do point me somewhere, please make sure it answers this specific question clearly.
Wildcard: yes. Any subdomain? No. That would require another _acme-challenge CNAME label in front of that specific subdomain.
While technically the CA/Browser Forum Baseline Requirements do allow issuance of subdomains once a certain domain has been validated (might be limited to certain types of challenges tho), Let's Encrypt does not allow this.
E.g.:
With Let's Encrypt, the challenge (or in your case, a CNAME) for _acme-challenge.example.com would allow issuance of certs with hostnames example,com and *.example.com, but notfoo.example.com. This latter hostname would require a challange or CNAME for _acme-challenge.foo.example.com.
You could limit issuance for non-wildcard certificates using a CAA resource record by the way.
Doesn't the hosting provider have vastly dangerous "permissions" already?
And really? IMO, this is an inane comment:
"Doesn't the hosting provider have vastly dangerous "permissions" already?"
Oh, so they have keys to the office, why not give them check signing authority too, eh?!
Yes, whoever hosts a website can do bad things with that website. But we don't have to give them more privs than they need to do their job, and we shouldn't. Signing a cert for the FQDN's for the web-server - sure we need them to do that. Signing certs for other FQDN's - no they don't need that, and shouldn't have it - even if they could do bad things with the website and it's certificate.
Further, what happens when the hosting provider gets compromised. Perhaps we trust the hosting provider, but we probably shouldn't trust their attackers, right? So, limiting scope really makes sense.
Acting as though there's only two options - trust them (with everything) or nothing, seems willfully ignorant.
I appreciate the answer on the base question though!
I feel like there should be a way to prevent the vendor from getting a wildcard cert using CAA records despite the CNAME. But re-reading the CAA specs has me second guessing whether it's possible. Anyone know for sure?
Having a cname repoint for [_acme-challenge.www.example.com] to their DNS keeps them in the www.example.com or *.www.example.com scope.
Yes, they could potentially do all sorts of mischief using the www. subdomain, if so inclined, but they couldn't , for example, stand up a mail server (or MITM) mail using a validly signed cert for mail.example.com - to use just one example.
So, yeah, it's not as small a closet as I'd like, but it's as small as we can practically construct, given all the political realities of the construct - and I can live with that.
I also looked at the spec right now and I don't see an obvious problem with restricting issuance via CAA in this case. RFC8659 simplified the path traversal algorithm, which previously required checking both the original FQDN tree and all CNAME trees. Checking the CNAMEs is now optional, but you always have to check the FQDN tree of the original, "before CNAME", domain. This is both in RFC6844 and 8659.
As I understand OP, they have to point _acme-challenge.www.example.com to an external hosting provider. They might also have to point www.example.com via CNAME to the hosting provider, @gsloop has not clarified this as I understand this thread. However, even if that is the case it is still possible to put a CAA record on the SLD example.com, which is very likely not CNAME'd.
A CAA issuewild ";" on either www.example.com or example.com prohibits any CA from issuing a wildcard for the corresponding FQDNs and subtrees of it. This applies independently of whether www.example.com (or a subtree of it) is pointed via CNAME to someone else. The CAA climbing algorithm always checks up to the TLD of the FQDN to be validated.
So, in order to come back to @gsloop's original question:
I believe that you can forbid the issuing of wildcard certificates for the (sub-)domains you own via CAA. CAA has a subtype called "issuewild" that controls the issuance of wildcard certificates only. You can use a record like:
www.example.com. IN CAA 0 issuewild ";"
or alternatively
example.com. IN CAA 0 issuewild ";"
to forbid the issuance of wildcards. The CAA record applies for the FQDN it is hosted on, and for all subdomains of it. You cannot put a CNAME and a non-CNAME record on the same FQDN, so if www.example.com is a CNAME, you can only put a CAA on example.com, which will then be applied to www.example.comand all other subdomains automatically.
CAA with CNAMEs used to be (and partially still is) a nightmare, because its not obvious how the FQDN tree is walked up when there are CNAMEs in between. This was especially confusing in older RFCs, newer RFCs have simplified it, altough, looking at RFC8659 section 3, it could have been formulated much clearer.
Yes, but if _acme-challenge.www.example.com is delegated to a hosting provider (for the purposes of hosting www.example.com), there is a possibility that www.example.com is also a CNAME to the same hosting provider. This complicates things with regards to CAA, but even then it should still be possible.
Doesn't the issue tag allow both wild and non-wild certs? So it wouldn't matter what's in issuewild? Or does the empty issuewild effectively cancel out the allowed wildcards in issue?
Nevermind. Just saw @Nummer378's answer to this earlier in the thread.
The discussion of the CAA is kind of academic to me.
Blocking wildcards of www.example.com might be modestly handy, but not worth a lot of effort, I think.
But, to further that discussion - yes, I'd expect to potentially have a CNAME for the www record too. (But that's certainly not a guarantee.)
In the past, for this setup, we usually set an A record for the root (example.com) to the IP of the host server, provided by the vendor, and then a CNAME for www.example.com to the root.
I'm not sure of the impact, either of those methods has, on the discussion.
In that case I don't understand your question at all. I thought all you wanted was to limit the amount of power the delegated provider has over your domain. For certificates, a reliable way to do this is via CAA.
Yes there is, by using CAA.
(I did check the BRs to see whether you could issue wildcards validated via HTTP-01 challenges. The current version of the BRs seem to no longer allow this. Otherwise I would have stated that CAA is the only way)
@Nummer378
I certainly don't want them issuing wildcards for *.example.com.
Limiting them for *.www.example.com might be handy - but doing that is more limited in its benefit.
I assume the CAA we're talking about doesn't apply to *.example.com - since the scope of the CNAME point for _acme-challenge.www.example.com already does that.
If I'm wrong about that, and still need the CAA to prevent wild-cards for *.example.com then this additional discussion becomes a lot more relevant.
DNS control over _acme-challenge.www.example.com allows:
Issuance of a certificate for www.example.com
Issuance of a certificate for *.www.example.com
A prohibitive CAA wildcard record can prevent the latter, which reduces the scope to simply:
Issuance of a certificate for www.example.com
Which is identical to what someone can do with the HTTP-01 challenge.
That depends on where you place the CAA record. CAA records apply to all lower levels, but CAA records on lower levels can override higher ones, which allows a fine grained level of control.
I'll add a thought or two.
I don't have a need right now, but it's possible I'd want to issue a wildcard certificate myself for the root (*.example.com). If I setup a CAA then I can't do that, right?
So, provided I understand the above, I may not have any option to setup a CAA to prevent a wild-card, if I ever want to setup my own wild-card cert. (Though I could setup the CAA until then, and take advantage of it while I can.)
