CAA checking becomes mandatory for SSL/TLS certificates

Tired of the privacy invasion of the Chrome webbrowser? Worried about the risk of seeing ads everywhere? Give the Brave Browser a try. It supports all the same Chrome extensions, with none of the telemetry. It auto-blocks ads and helps support content creators like me.

Give the Brave browser a try »

Profile image of Mattias Geniar

Mattias Geniar, April 08, 2017

Follow me on Twitter as @mattiasgeniar

This was news to me in a few ways; first, there's a new DNS resource record called CAA (Certificate Authority Authorization) and second, Certificate Authorities are now required to check that record before issuing a certificate, to determine if they're allowed to do so.


What's a CAA (Certificate Authority Authorization)?

When in doubt, consult the RFC: RFC 6844,  DNS Certification Authority Authorization (CAA) Resource Record.

In short, it looks like this: CAA 0 issue ""

The CAA record is a new resource record, next to the usual A, CNAME, MX, TXT, … records you might already know.

The syntax is as follows;

CAA <flags> <tag> <value>

Which translates to;

  • flag: An unsigned integer between 0-255.
  • tag: An ASCII string that represents the identifier of the property represented by the record.
  • value: The value associated with the tag.

In reality, you'll see the configurations mostly as follows; CAA 0 issue ""

-> this means that only Let's Encrypt can issue a certificate for the domain “”. Note this also covers the subdomains, like www. CAA 0 issue "" CAA 0 issue ""

-> this means both Let's Encrypt and Globalsign can issue certificates for the domain “”. CAA 0 issuewild ""

-> the issuewild tag indicates that wildcard certificates can be issued for “”, covering “*”, but not “*”.

Receiving notifications of CAA violations

If a certificate authority receives a certificate request for a domain, but the CAA record denies it, the CA can send a notification to the domain owner. This is configured & managed via the iodef tag.  CAA 0 iodef ""

-> this configures it so that if a CA receives a certificate request for “”, you'll be notified on “”.  CAA 0 iodef "/callback"

-> this configures it so that a HTTPS call will be done to that URL to inform you of this certificate request attempt. It's unclear whether it's a GET or a POST or what the payload is, that might depend on the CA?

Query'ing CAA records

Alas, this doesn't work yet in dig, as you get the A record if you query for a CAA record.

$ dig CAA		143	IN	A

Current versions of dig don't understand the CAA record yet, so you have to be explicit and query for Resource Record Type 257, the identifier given to CAA.

$ dig type257		86399	IN	TYPE257	\# 19 0005697373756573796D616E7465632E636F6D		86399	IN	TYPE257	\# 15 00056973737565706B692E676F6F67

Notice how the value isn't exactly readable? That's because it's binary encoded and needs to be decoded first, to be human readable.

Update: the dig version on CentOS 7 works just fine.

$ dig -v
DiG 9.9.4-RedHat-9.9.4-38.el7_3.2
$ dig CAA		86400	IN	CAA	0 issue ""		86400	IN	CAA	0 issue ""

Tools like dnscaa provide that ability.

$ ./digcaa 86399   IN  CAA 0 issue ""

Support for CAA records are coming in the next version of DNS Spy, too.

Do I have to add CAA records to get a certificate?

No, just like HSTS, the CAA records are completely optional. You should add them, for increased security though.

As of September 2017, Certificate Authorities are obligated to check for CAA records and honor those preferences. Not having CAA records is essentially the same as saying “everyone can issue a certificate for my domain”.

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.