April 15, 2026, 3:45pm 1
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).
Correct.
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.
5 Likes
rmbolger April 15, 2026, 5:57pm 3
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.
3 Likes
jeaton3 April 15, 2026, 7:25pm 4
That's entirely the problem.
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.
Oh well.
rmbolger April 15, 2026, 7:51pm 5
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.
3 Likes
MikeMcQ April 15, 2026, 7:57pm 6
Have you considered adding a CAA record at your top level that allows only your vendor's ACME account to use LE for your domain?
Like shown at these examples: Certificate Authority Authorization (CAA) - Let's Encrypt
2 Likes
jeaton3 April 15, 2026, 8:28pm 7
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.
rmbolger April 15, 2026, 8:57pm 8
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.
4 Likes
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.
Boulder (the ACME server implementation used by Let's Encrypt) will check all CAA records for the relevant domain to test whether any of them authorise the issuance. The code for this is at boulder/va/caa.go at e987484a9fd4931bf4c25c3c0c82f7dd3f11e13e · letsencrypt/boulder · GitHub
1 Like
ooh then its no problem for the OP. Then he can make multiple letsencrypt records with different accounturi parameters.
I tought the parsing logic was, "stop at the first CAA record that is "yours" and then read the parameters".
but in this case its simple for the OP to just authorize the accounturi for his all "sub-customers", without opening up his whole domain for issuance.
I asked a very similar question a couple of weeks ago, maybe this thread will help you how CNAME records work.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。