On September 8, 2017, it will be mandatory for Certificate Authorities (CA) to check the Certificate Authority Authorization (CAA) records of a domain before a certificate may be issued. The CAA record specifies which Certificate Authorities are allowed to issue certificates for different portions of their namespace. We have seen numerous cases where Certificate Authorities issued unauthorized certificates. An example of this was when WoSign created certificates for github.com. The first step to mitigating this risk is to configure CAA Records for your namespace.
What is a CAA record and what do they look like?
The CAA record was defined in RFC6844 in 2013 and didn’t receive much, if any, attention until recently when the CA Browser forum created a ballot initiative to make verification mandatory. The CA Browser forum “are a voluntary group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing”. On March 8th, the voting period for Ballot 187, “Make CAA Checking Mandatory,” closed. Nineteen CAs voted on this ballot and 94% were in favor as well as 100% of web browser voters (3 people). As a result, CAs must start checking the CAA records for each dNSName in the subjectAltName extension of the certificate.
Per the RFC a CAA record (Resource Record Type 257) has the following properties:
CAA Where: Flags: Is an unsigned integer between 0 and 255. Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. Value: Is the encoding of the value field as specified in [RFC1035], Section 5.1.
An example of a CA record:
containercult.com. IN CAA 0 issue “letsencrypt.org"
The “0” flag is a signal that a CA may continue to issue a certificate if it does not understand the record.
containercult.com. IN CAA 128 issue "letsencrypt.org"
The “128” flag is a signal that the CA may not issue a certificate if it does not understand the record.
On March 9th, the first amendment to the ballot initiative came in the form of a clarification about the failure mode. The original wording: “CAs MUST respect the critical flag and reject any unrecognized properties with this flag set” was replaced with, “CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property with this flag set.” The main goal is to express that this system should fail closed.
The other component to CAA record configuration is the scope of the record, defined by the tag issuewild. For example, if I want to allow Let’s Encrypt to issue certificates for only contianercult.com and not justanother.containercult.com or allabored.containercult.com, I would specify the issue and issuewild records as below:
containercult.com. IN CAA 128 issue "letsencrypt.org" containercult.com. IN CAA 128 issuewild ";"
However, if I wanted to specify that Let’s Encrypt is able to issue certificates for all of the domains in the containercult.com namespace (*.containercult.com), I would create the following entries:
containercult.com. IN CAA 128 issue ";" containercult.com. IN CAA 128 issuewild "letsencrypt.org"
Not only is there an issue tag and an issuewild, but there is also a tag dedicated to reporting.
containercult.com. IN CAA 128 iodef "mailto:firstname.lastname@example.org”
The iodef, Incident Object Description Exchange Format, entry is intended to be implemented to automate feedback related to certificate requests. It can be used by CAs to report issuance attempts that failed to meet the CAA policy of a site to the site itself (via email or a web service). IODEF is defined in RFC5070.
Why wait to until the last min? Add CAA records today! If you need a hand, there are some tools for generating and configuring your CAA records.