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


#1

The domain 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 does have a CAA record that has only Digicert listed in it. The link 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
token: a_F3j-4qk2vBk5ZMSUi_Zxlgzv-OnzrBPvjshNRteCk
status: Invalid
error: CAA record for content-ci360.sas.com prevents issuance
validationStatus: READY
requestTimestamp: 2018-10-29T15:05:00z
validatedTimestamp: 2018-10-29T16:07:34z


#2

Hi @sakrpa

the CAA check

https://sslmate.com/caa/

doesn’t find a specific CAA policy:

content-ci360.sas.com does not have a CAA policy. Any certificate authority can issue certificates.

This result

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 is used.


#3

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


#4

@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
content.aimatch.com.
aimatch.edgekey.net.
e10517.g.akamaiedge.net.
23.195.74.28


#5

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.


#6

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


#7

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


#8

@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:

$ 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:

dig sas.com caa
dig com caa

#9

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

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 :wink:

Cheers,
sahsanu


#10

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 :wink:
CAA is not domain transitive.


#11

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
then isn’t there a fallback lookup to
example.com
for a default CAA policy? Or do CAA records not apply to subdomains?


#12

Yes, there is. (And to “com”, too!)


#13

The “original” CAA request against domain “sas.com” will never be directed to the CNAME domain.