A Comprehensive Look at CAA

If you’ve ever purchased an SSL/TLS certificate for your site, you know that it’s specific to your domain and can’t be used for any other one. Every major browser shows certificate information for users to verify its legitimacy, but prior to CAA entries any authority could create certificates for a domain. A rogue CA could issue certificates for high profile domains and trick users into trusting a malicious site. Certificate Authority Authorization (CAA) is a security measure that helps stop unauthorized issuance of certificates by using a DNS entry to indicate who has authority to issue one. Together with ), CAA security stops fraudulent certificates from being issued.

What is CAA?

add trust to a site, so if they are fraudulently issued it can have dire consequences for users. A malicious site with an unauthorized certificate could host malware or be used for phishing. When you go to your bank’s website and view the certificate, you trust that they are securing your information with the proper SSL/TLS protocol. If you saw another site with a certificate for the same bank, you would probably trust it.

In October 2015, Google found that Symantec was issuing rogue HTTPS certificates for websites impersonating the search engine’s domain, which violates baseline requirements for CAs. This led to an 18-month review of Symantec’s practices, which later led to Google updating Chrome to reject any certificates issued by Symantec-owned Certificate Authority (CA) businesses.

CAs are required to follow baseline requirements before issuing certificates. Beginning September 2017, a CAA entry is now a part of these baseline requirements. A CAA is a DNS record added by a domain owner to provide a list of CAs authorized to issue certificates. All CAs are required to check these records before issuing a certificate to a requestor.

The advantage of using DNS is that aside from phishing a user’s login credentials, DNS settings are only accessible to the person who owns the domain. A CA that views CAA entries is assured that only the owner of the domain set up authorization. It’s a security measure that protects the integrity of the domain and the organization.

CAA Image

What Does a CAA Entry Look Like?

Anyone familiar with DNS entries will find CAA records easy to work with. A CAA has a specific format that must be followed. Syntax and property values are defined by RFC 6844. The following elements are required for an entry:

  • flag: an unsigned integer between 0 and 255. A flag of 1 (critical) means that the CA must only issue a certificate if the property tags are clearly defined and contain the right information.
  • tag: a string that represents the identifier of the property.
  • value: the value for the tag.

There are currently three defined tags:

  • issue: authorizes a single CA to issue a certificate for a specified domain or subdomain.
  • issuewild: authorizes a single CA to issue a wildcard certificate for a domain or subdomain.
  • iodef: the URL or email address where a CA can report violations.

Using these RFC specifications, you can then create DNS entries for your own domain. Let’s take a look at a few examples. You need an entry for each CA that you authorize.

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

In the above example, DigiCert is authorized to issue certificates for yourdomain.com.

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

Since you need an entry for each CA, the above example shows how you authorize more than one authority.  If you change “issue” to “issuewild,” it indicates that the CA can issue a wildcard certificate, which means that all subdomains are also covered by the certificate. If you don’t receive a wildcard certificate, then each subdomain must have its own certificate. You can set a default CAA for the domain and then set individual entries for subdomains.

yourdomain.com.    CAA 0 issue “comodoca.com”a.yourdomain.com.  CAA 0 issue “comodoca.com”b.yourdomain.com.  CAA 0 issue “digicert.com”

In this example, Comodoca is the default CA for yourdomain.com, but only DigiCert is authorized to issue certificates for the subdomain b.yourdomain.com.

If you prefer a wildcard domain, you must use “issuewild” instead of issue. With a wildcard certificate, viewers will see *.yourdomain.com when they inspect your SSL/TLS certificate. This can be convenient for businesses that control and own their own subdomains. You shouldn’t allow a wildcard certificate if any third-party (customers or vendors) use subdomains on your domain. This would validate SSL/TLS authority on subdomains that could be malicious. If you want to allow issuance of a wildcard, use the following CAA syntax:

yourdomain.com.  CAA 0 issuewild “digicert.com”

In this example, DigiCert can issue a wildcard certificate for yourdomain.com.

The final entry is the iodef tag that can be used for reports of violations. It can be an email or a URL. The following is an example of an iodef entry.

yourdomain.com.  CAA 0 iodef “mailto:webmaster@yourdomain.com”

It’s critical that you use the right syntax in your CAA entries. Any mistakes can lead to either issuance of a certificate from an unauthorized CA, or you could have problems getting a certificate the next time you need one.  You can validate your CAA records using online tools such as DNS Spy.

What Does This Mean for Businesses?

Before a CAA was added to baseline requirements, an IT staff member could go to any CA and order a certificate. Checks are put into place to verify the requestor, but any CA could be used and any type of certificate could be issued. Now, IT must set up the proper entries on your DNS server.

Where you add these entries depends on where you host DNS. For smaller organizations, most DNS servers are located at the web host. You may also have the host as the registrar, so you only have one place to go to set up DNS. If you host your own DNS servers or use cloud-based servers, you must enter your CAA records on your own servers or in the cloud service provider’s dashboard.

It might seem like an unnecessary change to CA requirements, but RFC 6844 added to baseline requirements protects your business from unauthorized certificates. CAs can have their certificates invalidated and unrecognized by major browsers, so any legitimate authority will follow the requirements. If you haven’t already set up your CAA records, you should do it soon to ensure that any new certificates will be issued without rejection from the CA.