Hi, I'm trying to understand the CAA issuance policy when it comes to CNAMES.
I have the following situation:
jeaton.org. 3600 IN CAA 0 issue "sectigo.com"
foo.jeaton.org. 3600 IN CNAME bar.jeaton.com.
bar.jeaton.com. 231 IN CNAME prod-cf-alb-XXXX.us-east-1.elb.amazonaws.com.
foo.jeaton.org (CNAME in my domain) points to a vendor hostname. Vendor hostname is a CNAME to their amazonaws instance.
I want to allow the vendor to have a letsencrypt.org certificate issued for foo.jeaton.org, which they manage fully.
Right now, as I understand it, letsencrypt will attempt CAA verification. Because they are CNAME records, those are followed and the CAA for prod-cf-alb-XXXX.us-east-1.elb.amazonaws.com is requested. There is no CAA record there, so it walks up the original hostname tree, from foo.jeaton.org to jeaton.org, and finds the CAA policy there which limits issuance to Sectigo, and denies the request.
Since foo.jeaton.org is a CNAME, I can't create a CAA record there. Since bar.jeaton.com is a CNAME, the vendor can't create a CAA record there. Amazon presumably won't create a CAA record for their domain name (I don't actually know, since I'm not Amazon's customer).
Is the only solution to allow letsencrypt.org at the prod-cf-alb-XXXX.us-east-1.elb.amazonaws.com or at the top level of jeaton.org ? I can't do the former, and I don't want to do the latter.
If this is the case, this seems like a fundamental design flaw in using CAA records with CNAMEs, instead of allowing something like _caa.foo.jeaton.org (which I could create).
If the vendor wants to be the one to manage and have certificates issued, the CNAME should point to their hostname that does have a CAA record for the providers they're planning on using. It probably shouldn't be a CNAME to some provider like AWS that wouldn't allow for that sort of thing. But a lot of vendors don't know how to handle this properly.
Yes. (Or, change the CNAME to point somewhere else. or to not be a CNAME.)
Well, I can see how it was a choice of tradeoffs that aren't the same choices everyone would have made. But CAA isn't exactly new at this point, and vendors would hopefully know the requirements by now.
ACME specifics aside, ultimately CNAME records are just delegations. You as the zone owner are giving control over that particular FQDN to a 3rd party for all record types which includes CAA records.
You don't get to decide what sort of cert the vendor will get when you point your records to their namespaces. If they need a cert, they can deal with it because they now control that name. If they need a CAA record for whatever CA they choose to use, they'll have to create it on their own.
The vendor wants to get a letsencrypt.org cert. I want to allow them to do so specifically for this hostname. Given the use of CNAMEs, I can't set one to exempt it from my top-level domain policy. Because the vendor runs on top of AWS and uses CNAMES pointing to AWS for their servers, they can't set one either, only Amazon can. So now no one can get a cert for the service.
I'm trying to work with the vendor to see if they can use my preferred CA, but if not, we're going to be stuck either opening up the entire domain to allowing the entire domain to get letsencrypt certs, or having to rearchitect the service.
I wish I knew why they went with a new RR type instead of a DKIM-like _caa.example.org TXT record.
If the vendor is running their infrastructure on AWS, why are they trying to get a Let's Encrypt cert instead of an AWS ACM cert which is also free and easily integrates (including automatic renewals) with AWS services such as ALB/NLB?
In any case, it shouldn't be your problem. It's the vendor's problem to deal with.
If I had a nickel for every time I've asked "why doesn't the vendor..."
It may not be my fault, but it is my problem.
Thanks all for your help. I have to fight my way through vendor support to talk to someone who can actually tell me what they can do, since I can't really do anything to fix this.
If they can tell you why they think they need a Let's Encrypt cert specifically, we might be able to provide guidance. My gut says they're trying to get an LE cert for the origin/backend boxes sitting behind the AWS ALB which is totally unnecessary. Last I checked, ALB does zero cert validation between itself and the origin servers. So you can use any origin cert you want including self-signed, expired, etc.
Why is that a problem? If you need multiple accounts to be able to issue LE certificates, you could limit it to methods, like "letsencrypt.org;validationmethods=dns-01"
This will prevent for example end user customers, from validating with http-01 while having no DNS access, while subvendors still can issue certificates.
However, this still requires Amazon to set up the actual validation records - but maybe their panel actually have support for validation records, as opposed to CAA records.
Another way is to use the accounturi parameter, and then simply sharing account private key with those that should be able to issue for your domain.
For what I know, lets encrypt won't parse multiple CAA with "letsencrypt.org;accounturi" and will stop at the first one.
