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.

Cool!

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:

ttias.be. CAA 0 issue "letsencrypt.org"

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;

ttias.be. CAA 0 issue "letsencrypt.org"

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

ttias.be. CAA 0 issue "letsencrypt.org"
ttias.be. CAA 0 issue "globalsign.com"

-> this means both Let's Encrypt and Globalsign can issue certificates for the domain "ttias.be".

ttias.be. CAA 0 issuewild "letsencrypt.org"

-> the issuewild tag indicates that wildcard certificates can be issued for "ttias.be", covering "*.ttias.be", but not "*.mail.ttias.be".

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.

ttias.be.  CAA 0 iodef "mailto:m@ttias.be"

-> this configures it so that if a CA receives a certificate request for "ttias.be", you'll be notified on "m@ttias.be".

ttias.be.  CAA 0 iodef "https://ma.ttias.be/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 google.com CAA
google.com.		143	IN	A	172.217.17.142

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 google.com type257
google.com.		86399	IN	TYPE257	\# 19 0005697373756573796D616E7465632E636F6D
google.com.		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 google.com CAA
google.com.		86400	IN	CAA	0 issue "pki.goog"
google.com.		86400	IN	CAA	0 issue "symantec.com"

Tools like dnscaa provide that ability.

$ ./digcaa google.com
google.com. 86399   IN  CAA 0 issue "symantec.com"

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. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.


Share this post

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

Comments

Georg Sauthoff Saturday, April 8, 2017 at 20:26 - Reply

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 google.com caa
google.com. 86231 IN CAA 0 issue “symantec.com”
google.com. 86231 IN CAA 0 issue “pki.goog”


Sebastian Bork Saturday, April 8, 2017 at 22:36 - Reply

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


Jovica Monday, April 10, 2017 at 10:41 - Reply

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


Citillara Monday, April 10, 2017 at 11:37 - Reply

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

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

What is your source for the date of september 2017?


Patrick van Staveren Monday, April 10, 2017 at 14:53 - Reply

Further reading on the CA/Browser Forum’s decision to make CAA record checking mandatory: https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/


Headcrack Monday, April 10, 2017 at 23:13 - Reply

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 *