Why Use CAA?
A CA always uses methods of domain validation to make sure every SSL/TLS certificate request is authorized (usually by making sure it is linked in some way to a particular site using that domain).
For instance, a CA might provide a special verification file to the requester. Placing this file on the website proves that the requester also controls that site, but it cannot guarantee the legitimacy of that control. A hacker who gains control of a site might masquerade as the legitimate owner, and could then request and receive an SSL/TLS certificate that passes any CA’s standard checks and thus seems legitimate. They could then turn around and use that SSL/TLS certificate for mischief, on that site or elsewhere.
CAA helps block this kind of exploit by defining which CAs are allowed to issue certificates for a domain (or even restricting certificate issuance altogether). This limits the damage a hijacker can inflict – even if they have control of a site, they’ll have drastically fewer options to score a rogue SSL/TLS certificate.
How CAA Works
CAA uses DNS
The Domain Name System (DNS) is a crucial part of the infrastructure of the internet. The owner of any domain maintains DNS records (inside the so-called zone files) pointing their domain name to the IP address where their site is hosted, and lets us type google.com into a browser window instead of 216.58.194.46.
DNS records are commonly used as the “phone book for the Internet”, but DNS also allows for other types of special records which can assign other information to a domain name.
CAA Records
CAA uses a special kind of record called a Certification Authority Authorization Resource Record (CAA record). These are published using DNS, and the domain owner simply adds CAA records alongside his other DNS records. A CAA record includes a tag and a value, and the tag-value pair is referred to as a property. There is also a flag indicating how critical this property is. Here’s what one looks like:
example.com. CAA 0 issue "ssl.com"
Here, example.com is the domain this record applies to, and CAA lets us know what kind of record this is. The 0 is the flag (zero is the default – we’ll talk about this below). The tag is issue and the value (in quotation marks) is ssl.com, which together make up the property.
Flags
Flags have only two strictly defined states currently: 0 (non-critical) and 1 (critical). A critical flag tells the CA that it must completely understand the property tag to proceed. RFC 6844 leaves other possibilities open for user-defined flag use (we’ll talk about these below, too).
Tags
RFC 6844 defines the use of three common tags: issue, issuewild and iodef. (As with flags, it allows for other potential customized tag types.)
The issue tag
The issue tag specifies which (if any) CA is authorized to issue certificates for this domain. For example, the owner of the domain example.com can restrict certificate issuance to one CA (here, SSL.com) by using the following DNS zone file:
example.com. CAA 0 issue "ssl.com"
A domain owner can choose to set up multiple zone files for a domain:
example.com. CAA 0 issue "ssl.com" example.com. CAA 0 issue "comodoca.com"
The above records limit SSL/TLS certificate issuance for example.com to two CAs (SSL.com and Comodo.com).
The issue record also authorizes the named CA to issue certificates for any subdomains of the specified domain. A record allowing SSL.com can thus allow issuance of certificates for example.com and subdomains like www.example.com, mail.example.com and even the special wildcard subdomain *.example.com.
A CAA record can be used to restrict certificate issuance, too – this record tells certificate authorities using CAA that no SSL/TLS certificates should be issued for example.com and subdomains by any CA:
example.com. CAA 0 issue ";"
(The semicolon in this example means “don’t allow anything here“, but as we’ll show later it is also used to define custom parameters.)
Note that a standard issue tag permits the CA to issue a certificate for a wildcard unless modified by…
The issuewild tag
This tag specifies that a CA is authorized to issue wildcard certificates for the owner’s domain (i.e. *.example.com).
Wildcards are a special kind of catch-all subdomain, and special care and attention is merited when issuing wildcard certificates. The issuewild tag lets the domain owner define what CAs can issue certificates for wildcards separately from the main domain or other subdomains. issuewild tags take precedence over any issue tags. They use the same syntax as the issue tag. Some examples:
example.com. CAA 0 issue "ssl.com" example.com. CAA 0 issuewild ";"
The above allows SSL.com to issue certificates for example.com and all subdomains except for the wildcard *.example.com. (Neither SSL.com nor any other CA is permitted to issue wildcard certificates for example.com.)
example.com. CAA 0 issue ";" example.com. CAA 0 issuewild "ssl.com"
This example forbids all CAs to issue certificates to example.com and its subdomains, but creates an exception to allow SSL.com to issue wildcard certificates (and only wildcard certificates) for example.com.
The iodef tag
The third defined tag is iodef. This tag can be used to report invalid certificate requests to the domain owner, and they look like this:
example.com. CAA 0 iodef "mailto:certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
The top record gives the CA information needed to send an email notification to the address certissues@example.com. The second one directs the CA to post an incident message to a web service (set up for this purpose by the domain owner) at certissues.example.com. (Either or both of these methods can used, depending on how the CA and domain owner have set up their operations.)
iodef post messages use a standard format called the Incident Object Description Exchange Format or IODEF – hence the name. (IODEF is defined in RFC 6546.)
CA-defined flags and tags
CAA as described in RFC 6844 only specifically defines two flag states (0 and 1) and three tags (issue, issuewild and iodef). However, it leaves the design open enough for CAs to create and utilize custom tags and flags to define their certificate issuance process. Examples might be:
example.com. CAA 0 issue "SSL.com; policy=ev"
This record uses a standard issue tag with an extra parameter that instructs the CA to use their Extended Validation (EV) policy when issuing a certificate for this domain.
example.com. CAA 128 pca "PCA=12345"
The domain owner could use this record with a new, CA-defined pca tag to show that they have a Preferred Customer Account and sets the account number as a parameter. (The flag can be a custom value as well of up to 255.) Depending on how the CA sets up the account this could allow for particular billing methods, extra account-defined verification or other special handling.
Pros and Cons
Pluses…
The are several excellent reasons to use CAA. The main and most important advantage is CAA’s ability to greatly reduce the risk of certificate mis-issuance. This helps protect your domain, your business and your online identity. Potential attackers that may have found a bug in a particular CA’s software cannot exploit it to issue SSL certificates for your domain. Furthermore, using the iodef tag lets you get a report if an exploit is attempted.
CAA’s design increases security but can also allow for more detailed allocation of resources – for instance, a company could set up records to allow (or limit) the sales and marketing department to purchase SSL certificates for sales.example.com from a designated source.
In addition, CAA offers great flexibility. For a domain owner, it uses DNS resource records that are under their own control and can be changed as needed, so they are not tied to a specific CA (and can have more than one CA authorized with issue records for any given domain name). For CAs, even apart from customized uses, newly adopted rules by the CA/B Forum (the group which sets standards for CA and browser security matters) can allow CAA records to be used for validation purposes, providing another good reason to utilize them.
…and minuses
The single biggest issue with CAA is that it hasn’t been adopted by all CAs. The CA/B Forum’s Baseline Requirements (which all trusted CAs fulfill) instruct a CA to specify the degree to which it supports CAA in their online documentation. As of this writing, however, CAA use is only recommended, not required. Certificate authorities which are not compliant with CAA can still be targeted, and until CAA is in wider use a hijacker will likely be able to find a non-compliant CA willing to issue a rogue certificate.
A related disadvantage is that even when CAA records are place, a user cannot enforce its use by a certificate authority. A CA must be compliant with RFC 6844 in order for those records to be acted upon, and a non-compliant CA might simply ignore the domain owner’s express wishes as declared in their CAA records.
CAA must also be correctly configured by both the domain owner and a CA. Let’s Encrypt (which does support CAA) recently reported a minor issue with their code base which unfortunately led to CAA rules being ignored and the mis-issuance of six certificates. None of these were malicious exceptions (and kudos to the Let’s Encrypt team for resolving and reporting the issue within hours of discovery). However, this underscores that a compliant certificate authority must implement CAA flawlessly.
Another potential issue is CAA’s reliance on DNS. Unless a domain owner secures their name services this can be a vector for attack. RFC 6844 suggests implementing Domain Name System Security Extensions (DNSSEC), which uses digitally signed DNS records to authenticate data and combat the threat of DNS spoofing.
Finally, even with CAA in place and correctly implemented, a CAA record by itself cannot completely prevent issuance of rogue certificates. Although CAA is a useful and important tool to limit an attacker’s options, a hijacker with sufficient access (for instance, by controlling DNS or through social engineering) may be able to route around it.
Conclusion
Certification Authority Authorization has terrific potential as part of a broader security ecosystem, and widespread adoption and implementation of CAA will protect against mis-issuance of certificates. While it is unfortunate that not all certificate authorities currently support CAA, there is discussion on making this more strongly suggested or mandatory for all CAs. Although CAA alone will not stop every certificate mis-issuance it is a good step in the right direction, and SSL.com would like to urge you to consider using CAA records yourself.
References
- RFC6844: DNS Certification Authority Authorization (CAA) Resource Record
- RFC5070: The Incident Object Description Exchange Format
- RFC6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
- RFC4033: DNS Security Introduction and Requirements
- CA/B Forum Ballot 125 – CAA Records
- Wikipedia entry about DNS Certification Authority Authorization
