[This is a guest diary submitted by J. Edward Durrett, GCUX]
While going over an SSL report from SSL Labs [1], I noticed something that I had not seen before: a check for CAA records. Certification Authority Authorization (CAA) is a DNS record which restricts which Certificate Authority can issue a certificate for a given domain [2]. Lets say I get all my Certificates for example.org from Certificate_authority.com. I can specify in my DNS that only Certificates issued by Certificate_authority.com are valid for my domain. This is done with a CAA record, which looks like this in my domains zone le:
example.org. CAA 0 issue certificate_authority.com
CAA support is going to become a mandatory standard in Certificate issuance in September 2017 [2]. That means, in the process of Certificate issuance, it will be mandatory that the the Certificate Authority check for the existence of CAA records for the domains they are issuing Certificates to [3] [4]. Consequently, if you dont have a properly formatted CAA record for your domain, you might not get a Certificate.
Although it remains to be seen how Certificate Authorities implement this standard, failure to have a CAA record for a domain, or having an improperly formatted CAA record, may cause automated Certificate management to fail unexpectedly. This, of course would leave sites with expired/missing Certificates.
For sites running their own DNS, adding a CAA record to the zone is all that is needed. Current versions of BIND, for example, support CAA records so this can be done now. Procedures and scripts for setting up new domains need to be updated to reflect the additional step of adding CAA record before attempting to obtain a Certificate. In addition, in the event of changing Certificate Authorities, the CAA record would also need to be updated to reflect the new issuer.
For organizations that rely on third party DNS providers, the case is different. From a quick search of support pages, I only found a couple that support CAA records [5] [7]. That will probably change as September gets closer, but having a backup plan is never a bad idea.
The best reference document for I found CAA is RFC 6844 DNS Certi cation Authority Authorization (CAA) Resource Record [3]. The example I have above will work for most sites. The structure of a CAA is like this:
FQDN CAA flags property value
There are some things to note. It is possible for a domain to have more than one CAA record:
example.org. CAA 0 issue letsencrypt.org example.org. CAA 0 issue comodo.com
This would allow a Certificate to be issued from letsencrypt.org or comodo.com. This is useful in cases where the Certificate for the smtp server is issued by letsencrypt.org and the web server uses one from comodo.com.
There are three properties which can be specified issue, issuewild, or iodef [3]. issue means a Certificate Authority is allowed to issue a Certificate for the domain. To completely bar Certificates being issued for a domain, this configuration is possible:
example.org. CAA 0 issue
To only allow wild card Certificates, ones that would match *.example.org, to be issued, the issuewild property is used:
example.org. CAA 0 issuewild certificate_authority.com
For reporting, the iodef property can be specified. This tells the Certificate authority to send a report to either an email or an http/https service [3]:
example.org. CAA 0 issue certificate_authority.com example.org. CAA 0 iodef mailto:[email protected] example.org. CAA 0 iodef https://iodef.example.org/
In the above example, Certificate_authority.com can issue a Certificate for example.org and then Certificate_authority.com is directed to send an IODEF incident report to [email protected] and to the web service at https://iodef.example.org.
In all of the configuration examples above the flag is set as 0. Setting the flag to 128 instructs the Certificate Authority that the property is critical [3]. That is, the Certificate Authority must understand the property before issuing a Certificate.
Each Certificate Authority has some ANSWER SECTION: google.com. 86400 IN CAA google.com. 86400 IN CAA
0 issue pki.goog 0 issue symantec.com
86399
IN
TYPE257 # 19 TYPE257 # 15
By piping the encoded output through xxd, we can see the property and issuer the record specifies:
$echo 00056973737565706B692E676F6F67 | xxd -r -p issuepki.goog
The drill utility, found on FreeBSD, does support querying CAA records:
There is also a program written in Go called dnscaa which can be found on GitHub [6].
I searched through several domains looking for CAA records. This was not an exhaustive or scientific search, just a handful of domains. Outside of Certificate Authorities like Comodo and Symantec, Google was the only domain I found with CAA records. Considering that Lets Encrypt alone has issued Certificates for close to 35 Million domains [8], there is likely a significant portion of administrators who have not published CAA records. As issuers reach out to their customers, I would expect to see more records published in the coming months.
The addition of CAA records to DNS and the critical role they will play in Certificate issuance makes an already key part of infrastructure even more valuable. Both the suppression and spofing of records being sent to the Certificate Authorities could result in an attacker obtaining an unauthorized Certificate or causing a denial of service condition [3]. Communicating with Certificate Authorities certainly would justify a method of signing and validating DNS records. Luckily, there already is such a method DNSSEC.
Interestingly, this may ( finally!) encourage the wide spread adoption of DNSSEC. Although RFC 6844, says in section 4.1 the use of DNSSEC is strongly RECOMMENDED but not required, it goes on to say in section 6.4 Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets. [3]. If deploying DNSSEC is something that you have been putting o for the last 20 years, this might be a good time to revisit.
In conclusion, the CAA record type is relatively new to DNS yet with up to date infrastructure in place it is fairly easy to implement. The lack of CAA support by third party DNS providers might prove challenging for some organizations. As issuers roll out their policies for CAA validation, the impact of RFC 6844 will become clearer. There is plenty of time between now and September to test and adopt procedures for dealing with CAA and its role in Certificate issuance.
J. Edward Durrett, GCUX
[1] https://www.ssllabs.com/ssltest/index.html
[2] https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum [3] https://tools.ietf.org/html/rfc6844
[4] https://cabforum.org/pipermail/public/2017-March/009988.html
[5] https://support.dnsimple.com/articles/caa-record/
[6] https://github.com/weppos/dnscaa
[7] https://cloud.google.com/dns/overview#supported_dns_record_types
[8] https://letsencrypt.org/stats/
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.