CAA checking becomes mandatory for SSL/TLS certificates

Mattias Geniar, Saturday, April 8, 2017 - last modified: Saturday, August 5, 2017

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 ""

-> 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".

Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!


Georg Sauthoff Saturday, April 8, 2017 at 20:26 (permalink)

FWIW, the dig 9.10 on Fedora 25 (9.10.4-P6-RedHat-9.10.4-4.P6.fc25) does know about the record type caa:

$ dig caa 86231 IN CAA 0 issue “” 86231 IN CAA 0 issue “”


Sebastian Bork Saturday, April 8, 2017 at 22:36 (permalink)

You wrote “Note this doesn’t cover the subdomains, like www.” However, the RFC states: “This policy applies to all subordinate domains under” Therefore, you do not have to worry about adding a CAA record for all the subdomains or hostnames you use.


    Jimmy Andelhofs Sunday, July 30, 2017 at 00:50 (permalink)

    You are correct. issue also covers subdomains.


Jovica Monday, April 10, 2017 at 10:41 (permalink)

FYI, DiG 9.11.0-P3 on Gentoo does also know about the record type caa.


Citillara Monday, April 10, 2017 at 11:37 (permalink)

Adds a bit security but it’s nullified if hackers hijack your DNS server (like in that brazillian bank hack)

Public key pinning is overkill (if you do a single error you lock all your users out without trival ways to recover)

One thing browsers could detect is certificate degradation :
If you own an EV-cert and suddently the new cert is non-EV that should raise a hude red flags on browsers


Greg Monday, April 10, 2017 at 13:06 (permalink)

drill version 1.7.0 on FreeBSD 11-STABLE also knows about CAA. (drill comes from the Unbound project by NLNet Labs)


Thorben Monday, April 10, 2017 at 14:50 (permalink)

What is your source for the date of september 2017?


Patrick van Staveren Monday, April 10, 2017 at 14:53 (permalink)

Further reading on the CA/Browser Forum’s decision to make CAA record checking mandatory:


Headcrack Monday, April 10, 2017 at 23:13 (permalink)

These cert checks should be transfered to a dezentralized block chain.
Same for DNS.


Leave a Reply

Your email address will not be published. Required fields are marked *