Beginning September 7, 2017, the CA/Browser Forum Baseline Requirements will require all Certificate Authorities (CAs) to check for Certificate Authority Authorization (CAA) records before issuing certificates. Website operators and domain administrators do not need to make any updates to comply with this new requirement.

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.

Implementing CAA

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

-          example.com

For detailed instructions on how to add CAA records, including steps for a hosted DNS, please see our related support article.

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.

As mentioned above, we have created a few support articles to help with implementation and address some common errors. If you have additional questions about CAA, please don’t hesitate to contact us.