Be careful about CAA records on Cloudflare DNS

Our staff hosted some domain names on Cloudflare, and on a security check, we added CAA records for each of them. After that, We have already issued many certificates for these domains using Let’s Encrypt, everything was fine. Until we tried the same thing with AWS ACM, it failed.

Problem #1: Missing CA statements

One day, I was configuring AWS Cloudfront, and I needed a certificate for a specific domain name that was currently hosted on Cloudflare.

I configured the corresponding CNAME verification record on Cloudflare DNS, following the requirements of AWS ACM documentation, but the verification failed.

At first, I thought I should had made a mistake in the configuration, but after trying again, it still failed.

This time, I noticed a underlined label Status: Failed, and only when my mouse hovered over it could I see the complete error message: CAA record verification failed.

I checked the AWS ACM documentation again and found that CAA requires issue statements for all 4 CAs:

• amazon.com
• amazontrust.com
• awstrust.com
• amazonaws.com

However, the CAA record generated by a CAA generator contains only amazon.com, which (probably) caused the failure.

After adding the other 3 CAs, now the CAA record should look like this:

1example.com. 3600 IN CAA 0 issue "amazon.com"
2example.com. 3600 IN CAA 0 issue "amazontrust.com"
3example.com. 3600 IN CAA 0 issue "awstrust.com"
4example.com. 3600 IN CAA 0 issue "amazonaws.com"
5example.com. 3600 IN CAA 0 issue "letsencrypt.org"
6example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

OK, the CAA record is complete, but when I tried again, it still failed, and the error message was still the same.

Problem #2: The CAA records attached by Cloudflare DNS

I was confused at the time. I had already configured the corrected CAA records on Cloudflare DNS, why did it still fail?

So, I checked with the nslookup command, and the result was surprising:

 1> set type=CAA
 2> example.com
 3
 4Server:         127.0.0.1
 5Address:        127.0.0.1#53
 6
 7Non-authoritative answer:
 8example.com      rdata_257 = 0 iodef "mailto:[email protected]"
 9example.com      rdata_257 = 0 issue "amazon.com"
10example.com      rdata_257 = 0 issue "amazonaws.com"
11example.com      rdata_257 = 0 issue "amazontrust.com"
12example.com      rdata_257 = 0 issue "awstrust.com"
13example.com      rdata_257 = 0 issue "comodoca.com"
14example.com      rdata_257 = 0 issue "digicert.com; cansignhttpexchanges=yes"
15example.com      rdata_257 = 0 issue "letsencrypt.org"
16example.com      rdata_257 = 0 issue "pki.goog; cansignhttpexchanges=yes"
17example.com      rdata_257 = 0 issuewild "comodoca.com"
18example.com      rdata_257 = 0 issuewild "digicert.com; cansignhttpexchanges=yes"
19example.com      rdata_257 = 0 issuewild "letsencrypt.org"
20example.com      rdata_257 = 0 issuewild "pki.goog; cansignhttpexchanges=yes"
21
22Authoritative answers can be found from:

What the hell…Oh right, I see what’s going on…

To issue certificates for their CDN service, Cloudflare automatically attaches the issue and issuewild statements into CAA records, for every CA they are using.

That’s no problem, what really annoyed me is that they could have just written the issue statements, but they did write the issuewild statements, which means that other CAs without the issuewild statement were prohibited from issuing wildcard domain certificates.

If a domain’s CAA record contains only the issue statement and no issuewild statement, it means that the domain allows all CAs in the whitelist to issue both regular certificates and wildcard certificates. However, if you mixed issuewild and issue statements in CAA records, then each CA must have an issuewild statement to issue wildcard certificates and an issue statement to issue regular certificates.

In other words, in my CAA records, I did not restrict the type of certificate that the CA could issue, but the extra CAA statements attached by Cloudflare did it. And that’s why AWS ACM couldn’t issue certificates but Let’s Encrypt could.

Finally, I added the issuewild statements for each CA to the CAA records, and the problem was solved.