# CAA record for content-ci360.sas.com prevents issuance

**URL:** <https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083>\
**Category:** Issuance Tech\
**Created:** [October 29, 2018, 6:12pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083 "2018-10-29T18:12:38Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![sakrpa](https://avatars.discourse-cdn.com/v4/letter/s/9f8e36/32.png) [@sakrpa](https://community.letsencrypt.org/u/sakrpa)\
**Post date:** [October 29, 2018, 6:12pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/1 "2018-10-29T18:12:38Z")

</div>

The domain [content-ci360.sas.com](http://content-ci360.sas.com) is not able to finish the verification due to CAA check. We are seeing the text below when trying to finish the validation. The TLD [sas.com](http://sas.com) does have a CAA record that has only Digicert listed in it. The [link](https://letsencrypt.org/docs/caa/) here does mention that the subdomain CAA record takes precedence over the TLD. So, is there a different reason for the CAA check error here?

responseBody: a\_F3j-4qk2vBk5ZMSUi\_Zxlgzv-OnzrBPvjshNRteCk.-UApDbD3eQiu1uf5vf4xp-ZJv71AiycGGMuLtf06BnA  
fullPath: [http://content-ci360.sas.com/.well-known/acme-challenge/a\_F3j-4qk2vBk5ZMSUi\_Zxlgzv-OnzrBPvjshNRteCk](http://content-ci360.sas.com/.well-known/acme-challenge/a_F3j-4qk2vBk5ZMSUi_Zxlgzv-OnzrBPvjshNRteCk)  
token: a\_F3j-4qk2vBk5ZMSUi\_Zxlgzv-OnzrBPvjshNRteCk  
status: Invalid  
error: CAA record for [content-ci360.sas.com](http://content-ci360.sas.com) prevents issuance  
validationStatus: READY  
requestTimestamp: 2018-10-29T15:05:00z  
validatedTimestamp: 2018-10-29T16:07:34z

---

<div class="post-metadata">

**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\
**Post date:** [October 29, 2018, 6:19pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/2 "2018-10-29T18:19:08Z")

</div>

Hi @sakrpa

> [@sakrpa](#):
>
> The domain [content-ci360.sas.com](http://content-ci360.sas.com) is not able to finish the verification due to CAA check

the CAA check

[https://sslmate.com/caa/](https://sslmate.com/caa/)

doesn't find a specific CAA policy:

> [content-ci360.sas.com](http://content-ci360.sas.com) does not have a CAA policy. Any certificate authority can issue certificates.

This result

> **[DNS Checker - DNS Check Propagation Tool](https://dnschecker.org/#CAA/content-ci360.sas.com)**
>
> Check DNS Propagation worldwide. DNS Checker provides name server propagation check instantly. Changed nameservers so do a DNS lookup and check if DNS and nameservers have propagated.

is curious. Looks like there is an empty entry. Checking with my own domain the CAA - entry is listed.

PS: So the entry of [sas.com](http://sas.com) is used.

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [October 29, 2018, 6:28pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/3 "2018-10-29T18:28:58Z")

</div>

> [@sakrpa](#):
>
> The TLD [sas.com](http://sas.com) does have a CAA record that has only Digicert listed in it. The [link](https://letsencrypt.org/docs/caa/) here does mention that the subdomain CAA record takes precedence over the TLD. So, is there a different reason for the CAA check error here?

Subdomain `CAA` records take precedence _when they exist_. `content-ci360.sas.com` has no `CAA` records, so the ones from `sas.com` apply.

---

<div class="post-metadata">

**Author:** ![sakrpa](https://avatars.discourse-cdn.com/v4/letter/s/9f8e36/32.png) [@sakrpa](https://community.letsencrypt.org/u/sakrpa)\
**Post date:** [October 29, 2018, 6:45pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/4 "2018-10-29T18:45:30Z")

</div>

@mnordhoff Thank you for clarification. I also noticed that this domain a CNAME chain. If a domain has a CNAME chain, shouldn’t the CAA validation follow the chain and look for CAA record **only** for the domains it is CNAME’d to in the chain?

dig +short [content-ci360.sas.com](http://content-ci360.sas.com)  
[content.aimatch.com](http://content.aimatch.com).  
[aimatch.edgekey.net](http://aimatch.edgekey.net).  
[e10517.g.akamaiedge.net](http://e10517.g.akamaiedge.net).  
23.195.74.28

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [October 29, 2018, 6:51pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/5 "2018-10-29T18:51:51Z")

</div>

It basically does the equivalent of “`dig content-ci360.sas.com caa`”, “`dig sas.com caa`” and “`dig com caa`”, stopping when it finds a `CAA` record set, or encounters an error.

The `CAA` lookup algorithm used to be more complicated, but the standard was changed.

You need to either add a `CAA` record set on Akamai – if you can – or change the one on `sas.com`.

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [October 29, 2018, 7:23pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/6 "2018-10-29T19:23:06Z")

</div>

> [@mnordhoff](#):
>
> It basically does the equivalent of “ `dig content-ci360.sas.com caa` ”, “ `dig sas.com caa` ” and “ `dig com caa` ”, stopping when it finds a `CAA` record set, or encounters an error.

Maybe I'm wrong but as far as I can remember, it checks the CAA records in this way:

`dig content-ci360.sas.com caa`  
`dig content.aimatch.com caa`  
`dig aimatch.edgekey.net caa`  
`dig e10517.g.akamaiedge.net caa`  
`dig sas.com caa`  
`dig com caa`

It checks the origin domain, if it has CNAMES, it checks the CAA for every CNAME (but it does not perform a tree-climbing on those CNAMES as it did in Legacy CAA Implementation), if no CAA record found, it starts the tree-climbing on the origin domain, etc. till a CAA record is found, an error or till the end if there isn't CAA records.

Cheers,  
sahsanu

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [October 29, 2018, 7:39pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/7 "2018-10-29T19:39:22Z")

</div>

Right. My example left it to the DNS resolver to follow the CNAMEs.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [October 29, 2018, 10:22pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/8 "2018-10-29T22:22:48Z")

</div>

@sahsanu: @mnordhoff’s example is more accurate here. You’ll notice in the output from `dig content-ci360.sas.com` that the recursive resolver has already snapped the CNAMEs for you and found nothing at the end:

```auto
$ dig CAA content-ci360.sas.com 

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> CAA content-ci360.sas.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54651
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;content-ci360.sas.com. IN CAA

;; ANSWER SECTION:
content-ci360.sas.com. 3523 IN CNAME content.aimatch.com.
content.aimatch.com. 1674 IN CNAME aimatch.edgekey.net.
aimatch.edgekey.net. 498 IN CNAME e10517.g.akamaiedge.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Oct 29 15:21:19 PDT 2018
;; MSG SIZE rcvd: 147

```

So there’s no need to run a separate `dig` for `content.aimatch.com`, `aimatch.edgekey.net`, and `e10517.g.akamaiedge.net`. You can just move directly on to:

```auto
dig sas.com caa
dig com caa

```

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [October 29, 2018, 11:21pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/9 "2018-10-29T23:21:08Z")

</div>

@jsha, I was trying to explain how Let's Encrypt implements CAA checks because of this:

> [@sakrpa](#):
>
> If a domain has a CNAME chain, shouldn’t the CAA validation follow the chain and look for CAA record **only** for the domains it is CNAME’d to in the chain?

Of course, @mnordhoff example is accurate because of dig command follows CNAMEs but I wanted to show what are the steps to check the CAA records if the domain has CNAMEs... I should have used just a `check domain caa`, `check cname caa`... instead of dig command 😉

Cheers,  
sahsanu

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [October 30, 2018, 4:38am UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/10 "2018-10-30T04:38:17Z")

</div>

> [@sahsanu](#):
>
> `dig content-ci360.sas.com caa`  
> `dig content.aimatch.com caa`  
> `dig aimatch.edgekey.net caa`  
> `dig e10517.g.akamaiedge.net caa`  
> `dig sas.com caa`  
> `dig com caa`

This might be better visualized as:

`dig content-ci360.sas.com caa`  
`(which returns CNAME to content.aimatch.com)` [not relevant for CAA match]  
`(which returns CNAME to aimatch.edgekey.net)` [not relevant for CAA match]  
`dig sas.com caa`  
`dig com caa`

Or something like that 😉  
CAA is not domain transitive.

---

<div class="post-metadata">

**Author:** ![justinacolmena](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/justinacolmena/32/23254_2.png) [@justinacolmena](https://community.letsencrypt.org/u/justinacolmena)\
**Post date:** [November 4, 2018, 4:18pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/11 "2018-11-04T16:18:21Z")

</div>

> [@rg305](#):
>
> CAA is not domain transitive.

I am not exactly sure what you mean by this. There is still something I am not understanding quite right. If there is no CAA record for  
[subdomain.example.com](http://subdomain.example.com)  
then isn't there a fallback lookup to  
[example.com](http://example.com)  
for a default CAA policy? Or do CAA records not apply to subdomains?

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [November 4, 2018, 8:16pm UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/12 "2018-11-04T20:16:45Z")

</div>

> [@justinacolmena](#):
>
> If there is no CAA record for  
> [subdomain.example.com](http://subdomain.example.com)  
> then isn’t there a fallback lookup to  
> [example.com](http://example.com)  
> for a default CAA policy?

Yes, there is. (And to "`com`", too!)

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [November 5, 2018, 12:35am UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/13 "2018-11-05T00:35:45Z")

</div>

> [@rg305](#):
>
> dig content-ci360.**[sas.com](http://sas.com)** caa  
> (which returns CNAME to content.**[aimatch.com](http://aimatch.com)**) [not relevant for CAA match]  
> (which returns CNAME to aimatch.**[edgekey.net](http://edgekey.net)**) [not relevant for CAA match]  
> dig **[sas.com](http://sas.com)** caa  
> dig com caa

The "original" CAA request against domain "[sas.com](http://sas.com)" will never be directed to the CNAME domain.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [December 5, 2018, 12:35am UTC](https://community.letsencrypt.org/t/caa-record-for-content-ci360-sas-com-prevents-issuance/76083/14 "2018-12-05T00:35:51Z")

</div>

Closed on December 5, 2018, 12:35am UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.