CAA checking becomes mandatory for SSL/TLS certificates

Mattias Geniar, Saturday, April 8, 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 doesn't cover the subdomains, like www.

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

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

Comments

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

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”

Reply


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

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.

Reply


Jovica Monday, April 10, 2017 at 10:41

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

Reply


Citillara Monday, April 10, 2017 at 11:37

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

Reply


Greg Monday, April 10, 2017 at 13:06

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

Reply


Thorben Monday, April 10, 2017 at 14:50

What is your source for the date of september 2017?

Reply


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

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/

Reply


Headcrack Monday, April 10, 2017 at 23:13

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

Reply


Leave a Reply

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