DNS Certification Authority Authorization

Overview [1]#

DNS Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that DNS Domain.

DNS Certification Authority Authorization DNS Resource Records allow a public Certificate Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.

RFC 6844 defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.

DNS Certification Authority Authorization is part of the Identity Proofing during the Credential Enrollment process.

DNS Certification Authority Authorization is a proposal to improve the strength of the Public Key Infrastructure ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name for during the Certificate Request Process

September 2017#

Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the Certification Authority Browser Forum recently voted to mandate CAA support as part of its certificate issuance standard Baseline Requirements. The changes will become effective in September 2017.

CAA RR Type#

A CAA RR consists of a flags byte and a tag-value pair referred to as a property. Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name. The following flag is defined:
  • Issuer Critical: If set to '1', indicates that the corresponding property tag MUST be understood if the semantics of the CAA record are to be correctly interpreted by an issuer. Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.

Examples for CAA RR Type#

  • CAA 0 issue "ca.example.net"
  • CAA 0 iodef "mailto:security@example.com"
  • CAA 0 iodef "http://iodef.example.com/"

In the following examples, assume that we want to control certificate issuance for the domain example.com.

To signify that only the CA Let's Encrypt can issue certificates to the domain, as well as all of its subdomains, one may use the CAA record

example.com.       IN      CAA     0 issue "letsencrypt.org"

To disallow issuance for a specific subdomain, nocerts.example.com, one would allow issuance only to the empty issuer list,

nocerts.example.com.    IN      CAA     0 issue ";"

In this case, in a request to issue a certificate to nocerts.example.com, the relevant CA will stop its search for RAA records at the subdomain.

To signify that the CA may report certificate issues or policy violations by email to caa@example.com, or through RID messages to caa.example.com, the iodef property may be applied as follows:

nocerts.example.com.    IN      CAA     0 issue ";"
nocerts.example.com.    IN      CAA     0 iodef "mailto:caa@example.com"
nocerts.example.com.    IN      CAA     0 iodef "https://caa.example.com"

If, in the original example, we would like to allow issuance to specific domains, but disallow issuance of any wildcard certificates, the issuewild property may be applied:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

The critical flag is intended for usage when future inclusions of new properties may impact issuance. If, for example, a future version of CAA would include the tag "future", then the record set

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     128 future "Some value"
would result in no issuance, if the CA does not know how to parse the record, for instance if it has not yet updated its parsing engine to the new version.

More Information#

There might be more information for this subject on one of the following: