Let's say we have a domain domain.org , and that our current CAA configuration is like:
@ IN CAA 0 issue ";"
@ IN CAA 0 issuewild "digicert.com"
And we have specific records for sub-domains like:
dev IN CAA 0 issue "letsencrypt.org"
So we're allowing CAs to issue certificates only for specific sub-domains, denying any others.
It works well because there is no CNAME involved.
Now the question: we have a domain which is used for a third party service, that we don't manage but we use our own custom domain, let's say external.domain.org as follow. This third party service leverages letsencrypt.org. It's been added to our DNS like this:
external IN CNAME cname.thirdpartyservice.com.
As there is a CNAME record here, I can't add a CAA record on the same name external . Also it means that when this third party sercice try to renew the letsencrypt certificate for external.domain.org , it fails (by top-domain CAA record above). At the support from the third-party service, they are suggesting us to allow letsencrypt.org at our top-level domain. This will allow certificates issuance to letsencrypt.org for any sub-domains. If I do this, maybe I'm wrong but if a hacker gets control over a website subdomain of domain.org (somehow), he might be able to issue a valid certificate for that subdomain ? But maybe this case isn't realistic ?
What's the best practice for CAA records and externally certified sub-domains like this ?
Note: the support doesn't seem inclined to add a record for cname.thirdpartyservice.com. which I believe would be an alternative, working option, isn't ? (I've read the topic CAA validation error on CNAME lookup with on CAA record - #3 by TimJones which seems to confirm my understanding )
Convince the provider of cname.thirdpartyservice to add a CAA record there, allowing Let's Encrypt. This is probably what they should be doing long-term for all their customers, because if they're doing Let's Encrypt certification they should be protecting their systems with the CAA record to prevent other CAs from issuing for the names they're hosting. CAA is new enough that it may just be that companies don't know they should be using it yet.
As they suggest, add a CAA to your root domain allowing Let's Encrypt. This would allow for anybody who can fulfill a Let's Encrypt challenge for any subdomain that doesn't already have a CAA record to be able to get a certificate from Let's Encrypt, which I can see not being ideal but may be an acceptable risk.
Can you put it the CNAME another level up? Like have your external service be external.something IN CNAME cname.thirdpartyservce and then you can put a CAA record of something IN CAA 0 issue "letsencrypt.org" that just allows it for names above "something". I'm sure needing to change the URL of this service wouldn't be ideal, though.
Change your record to put direct A/AAAA records rather than a CNAME, so that you can add your own CAA record. This of course means they have to tell you when their IP changes, though some DNS providers have an "alias"-type feature where the DNS server looks up a name to present for the A/AAAA record but doesn't show it as a CNAME, so you can add your own other record types like CAA and TXT. This might not work for you, depending on why they wanted it to be a CNAME.
Rather than them using Let's Encrypt to get their certificate, they send you a CSR and you use the same CA as your main site uses to issue certificates for them. Your CAA would then need to allow that CA for both issue and issuewild. This is tricky to automate, of course.
As for "best practice", my vote would be for option 1, but I don't know as CAA has been around for long enough for there to be much experience available yet on the pros and cons.
I guess you mean adopting a black-list manner instead of white-list. The problem I see with it is I don't wont to forget to add a deny entry every-time I add a sub-domain. And BTW I have hundreds of sub-domains, so it doesn't look elegant to me to deny each of them explicitely that way.
Unless I missunderstand something, of course.
@petercooperjr : thank you for the very detailed answer ! I tried to convince the external service once again, and this time they proposed to leverage a ANAME record, unfortunately it's not implemented into BIND so I can't rely on this. I don't get why they don't want to put a CAA record for their name...
Remains two options: 1) sub-domain as you both suggested 2) add the CAA record to the root domain.
There's also my option 4, where you just list their A/AAAA records directly instead of it being a CNAME, which certainly can be a pain if they change IPs regularly (as they might if it's through like a CDN type thing). Or change your DNS hosting/server to something that supports Alias (or ANAME) records, if you really want to solve this no matter what.
Might be their current DNS server doesn't support it, and they don't want to upgrade their DNS software any more than you want to change yours. Or, adding records for all their customers might be a bigger project that needs more testing and planning, and they don't want to have a "special" configuration just for you.
Wait, maybe I'm missing something: wouldn't it be enough on their side to add a single CAA record for cname.thirdpartyservice.com. as cname.thirdpartyservice.com. IN CAA 0 issue "letsencrypt.org" ? I thought the algorithm was looking for a CAA record for the defined CNAME first, then search for parent domains.
Ah, if all their customers use the same cname I suppose it would just be one CAA record for everybody. I was assuming that each customer had their own specific individual name to use. Redacting domains can be tricky to really convey everything well.
In any event then, if all their customers use the same cname, then adding a CAA record to it would impact all their customers. Again, it probably would make sense for them to do so in order to protect all their customers from unauthorized issuance, but I could again see them wanting to do more testing and planning on a change that would impact all their customers at once.
Well indeed, just to clarify and be a bit more specific this time, it's about adding the (single) cname mentioned in Support | Campaign Monitor - it could be useful for anyone searching over the forum.
but I could again see them wanting to do more testing and planning on a change that would impact all their customers at once.
Well, from my perspective, I've been impacted in such way that adding CAA record on my top domain prevented the custom domain certificate to renew properly on their side (and we've not been warned about this failure). So we're impacted because I have added CAA records and that they have not added a CAA record against their CNAME record... Said differently could we think they are relying on the fact their customers won't have CAA (eg. no policy) or would never fall into the CNAME/CAA current case...? I'm not sure.
But of course that's only my subjective way of seing it, and I agree it should be studied before applied to all customers.
Yeah, I suspect the real issue here is that CAA is still fairly new (as security technologies go), and as you've noticed there isn't much in the way of best practices for using it around. The most common "using a vendor under our name" scenarios that I'm familiar with in my professional life have used my option 5, where the vendor sends a CSR every year that we send to our CA to get a certificate that we then send back to the vendor. (Also, my current employer prefers using OV certificates for everything that needs a public certificate, so there's that wrinkle in things as well.) While Let's Encrypt has been leading the charge for telling people to automate certificate issuance and installation everywhere, there are a lot of scenarios where that's not yet the standard. As quick as the IT industry moves in some ways, there are other ways in which it's pretty slow. Really having the vendor get their own certificates through Let's Encrypt is probably an improvement over the status quo, since that way they can automate the process. One day maybe everybody will have CAA records and DNSSEC and DANE and whatever-comes-next, but it may yet be a while before we get there.
