������

Earlier this year, new industry standards were adopted which made Certificate Authority Authorization (CAA) record checking mandatory for all Certificate Authorities.

This gives website administrators an additional tool for protecting their sites from mis-issuance, and a technical measure for enforcing an organization’s certificate policies.

Introduction to CAA

By setting up a CAA record you can control which CAs are permitted to issue certificates for your website. This addresses one of the key concerns of the Web PKI system—that any single CA can be used to compromise any website. Typically, only a handful of CAs are used by a single site, making it unnecessary to allow every CA in the world (on many platforms there are around 100 trusted CAs) to issue certificates for your site.

When a CA receives a certificate request, they must first query that website’s CAA record before validating or issuing the certificate. CAA records are a new type of DNS record that websites can optionally configure for these additional protections. In , new industry regulations required all CA’s to check for a CAA record before issuing a certificate.

CAA deployment has grown significantly this year. , which analyzes SSL configurations of the world’s largest sites, reports that the number of sites using CAA has doubled since September 2017, and increased more than tenfold this year. Even with that rate of growth, only a few thousand websites are using CAA and it remains a niche security mechanism.

One of the common misunderstandings about CAA is that websites are forced to use it. This comes from confusion over the core mechanics of CAA. By default, a website with no CAA record has no restrictions on which CAs may issue certificates to it.

A CAA record allows you to restrict the list of approved Certificate Authorities through a whitelist. For websites that are not interested in CAA, they do not have to make any changes. Simply don’t create a CAA record and every CA will be able to issue certificates for your domain.

Policy Enforcement

CAA is not only a security mechanism. In addition to minimizing risk by restricting the CAs authorized to issue for your domain, CAA is also a useful tool for enforcing company policies related to certificates.

Many organizations struggle with making sure that company policies related to purchasing, requesting, and deploying certificates are obeyed. This is especially true in large organizations with multiple offices or semi-autonomous departments. CAA can act as a technical measure for enforcing your certificate policy.

For example: say someone in engineering sets up a new service on your domain. If they attempt to request a certificate they will be restricted from using CAs you have not approved. You can optionally configure a reporting URL or email address to receive notice from CAs when they receive a request they are not permitted to issue.

Deploying CAA

CAA is a new security mechanism that can be used to strengthen your website’s SSL configuration and certificate policy. Given that most administrators have never deployed CAA, we have put together a short summary of the process. CAA is a rather easy mechanism to use, and carries significantly less risk of configuration or operational errors than other mechanisms like strict transport security (HSTS) or key pinning (HPKP).

There is a technical pre-requisite to using CAA. If you use managed DNS, your provider needs to have added support for CAA because it is a new DNS Resource Record. Many major providers, including Cloudflare, Dyn, and Route 53 support CAA. .

Here are guidelines for planning a CAA deployment, and an overview of how its deployment benefits your website security and organization’s policy:

1. Use your organization’s certificate policy as a starting point. If you have approved certain CAs as providers, use these to create the list of CAs you will enter into your CAA record.If you do not already have a certificate policy at your organization, at a minimum you will want to determine what CAs are commonly used by your organization. You can always update (or remove) your CAA record if you need to change the list of authorized CAs, and those changes take effect according to your DNS TTL.

2. Create a CAA DNS record. Your policy can be restrictive—scoped to only one or a handful of CAs your organization uses—or more flexible to allow your organization to use a larger number of popular providers. Even if your CAA policy permitted 10 CAs, this would still be a significant reduction.Here is an example of a CAA record which would only allow ������ to issue certificates for a website:

   yourdomain.com.������������ CAA 0 issue “digicert.com”

   This record would apply to all subdomains under the domain. ��If you wanted to permit additional CAs, a new line would be created for each CA. The hostname listed at the end identifies the CA, which each CA explicitly choses. That hostname may not be the same as the CA’s homepage, so make sure you check with your CA’s documentation for the proper syntax. to streamline this process. Note that you can set different CAA records for subdomains for more flexibility. CAA records are checked hierarchically in your DNS tree, starting at the highest label of the request. For example, if you requested a certificate for “sub.domain.com,” the CA first checks for a record for the subdomain, then the root domain if a record does not exist at the subdomain level. For CNAME’s the parent domain will be checked last.

3. For all future certificate requests your domain’s CAA record will be checked and any CA but ������ (in this example) must refuse to issue any certificates.As of September 8, 2017, the CA/B Forum now requires all CAs to obey a CAA record. This applies to all trusted CAs, including certificates provided for free and by cloud service providers. Failing to obey your record constitutes mis-issuance of the certificate which can lead to sanctions or dis-trust of the CA.

4. Your domain is now at reduced risk for mis-issuance. In an adversarial scenario, a potential hacker would be constrained to the CA(s) specified in your CAA record, creating less attack surface.Depending on how your CA implements account controls, this could make it impossible for attackers to receive certificates for your site, even if they compromised your web server. For example, if your CAA policy only permitted ������ to issue certificates for your site, there would be no way for the attacker to complete the OV/EV validation process.Employees or unauthorized users would similarly be restricted, which reduces violations of your org’s certificate policy. In the future, CAA could be expanded to allow for more fine-grained control, such as restricting validation type.

   In a scenario where a specific CA has vulnerabilities in their validation or issuance procedures, there is a reduced chance your domain will be affected. If CAA had been deployed and enforced in 2016, many of the highest priority mis-issuances in the Web PKI ecosystem may have been prevented.

CAA does have limitations. If a CA is acting maliciously—either because they have gone ‘rogue’ or have been compromised by an attacker—they can simply ignore what your CAA record says and issue certificates anyways. Individual websites are also at risk if their DNS is compromised. An attacker who can change your DNS settings could remove your CAA record, which would allow all CAs to issue for your site again. This could also be achieved with DNS record spoofing, though only very powerful attackers would have that capability.

A final note: CAA only addresses certificate issuance of trusted CAs. It is not intended to deal with scenarios where local root certificates are trusted on a device, such as a corporate intranet. Those roots would still be free to issue certificates for your domain as they are not regulated by root programs. This could be used to intercept or monitor traffic to your website on a local network.