Editor's Note: This blog was originally published in August of 2017. It has recently been updated to reflect the RFC 1912 guidleline for CNAME records.
CAA is a security measure that allows domain owners to specify in their Domain Name Servers (DNS) which CAs are authorized to issue certificates for that domain. If a CA receives an order for a certificate for a domain with a CAA record and that CA isn’t listed as an authorized issuer, they are prohibited from issuing the certificate to that domain or any subdomain.
Benefits of CAA
One of the benefits of CAA is to supplement Certificate Transparency (CT). CT provides mechanisms to help domain owners identify mis-issued or frequently issued certificates for their domains after issuance, while CAA can help prevent unauthorized issuance before the fact. Together they build a better set of security than either one by themselves.
CAA can also help organizations who have standardized, or want to standardize or limit the CAs they use. Prior to CAA, there was not an easy way for organizations to enforce this type of policy, but now that all CAs will have to check for CAA records, these policies can actually be enforced by the CAs.
While checking for CAA records is mandatory for CAs, using CAA is optional for domain owners. You can decide for yourself if you want to implement and, if you decide to do so, you can specify multiple CAs if desired (see cautionary notes later in this blog).
Here are the processing rules for CAs:
- No CAA record: CA can issue.
- CAA record includes CA: CA can issue.
- CAA record, but does not include CA: CA cannot issue.
CAA supports the following properties:
- Issue: Permits CAs to issue certificates (including wildcard certificates unless restricted by Issuewild)
- Issuewild: Permits CAs to issue a wildcard certificate, but not non-wildcard certificates.
Here is an example of the CAA code you would add to your DNS zone file if you wanted to authorize GlobalSign to issue certificates for example.com:
CAA 0 issue “globalsign.com”
Remember, CAA checking starts with the full FQDN and processes up to the Base Domain, so when validating the FQDN of www.us.example.com, the CA will check:
- www.us.example.com, then
- us.example.com, then
For detailed instructions on how to add CAA records, including steps for a hosted DNS, please see our related support article.
Note about CNAMEs:
In accordance with RFC 1912, A CNAME record is not allowed to coexist with any other data. When looking for CAA records, we will follow the above rules from the FQDN and walking the chain up but if we encounter a CNAME record we will ignore DNS TXT and CAA records for that domain. Instead of looking for a CAA record on the provided domain name, we will look for CAA records on the domain the CNAME points to.
Use Caution When Updating CAA
Be sure you use caution when creating CAA records. If you have other departments obtaining certificates you need to coordinate to be sure that all CAs in use will be added to your CAA records. Since CAA checking is mandatory and results in rejected orders that a CA can’t override, it’s important that the DNS administrator does not take down the company! Also, if you’re using a service provider for any of your hosting solutions, they may be securing those servers with a CA you don’t have a direct relationship with, so be careful.
As a quick check, you may want to query for certificates issued to your domains using https://crt.sh/ which will return a list of the issuing CAs for that domain. Don’t shoot yourself in the foot, make educated updates to CAA records!
GlobalSign and CAA
GlobalSign will start enforcing CAA on August 28, 2017.