Certificate Authorities check the CAA resource records prior to issuing a certificate

Before a Certificate Authority (CA) can issue an SSL/TLS certificate for your domain, they must check, process, and abide by the domain's DNS Certification Authority Authorization (CAA) resource records (RRs). (See Ballot 125 – CAA Records [PASSED], RFC 6844, and Ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag.)

CAA RRs Are Not Required

A CAA resource record is NOT REQUIRED for DigiCert to issue SSL/TLS certificates for your domains. The information provided here is only important if you are in one of these situations:

  • You already have CAA resource records set up for your domains.

  • You want to add CAA resource records for your domains.

For information about the benefits of CAA, see The Security Benefits of CAA.

How the CAA RR Process Works

Prior to issuing an SSL/TLS certificate for your domain, a CA (such as DigiCert) checks the CAA RRs to determine whether they can issue a certificate for your domain. A CA can issue a certificate for your domain if one of the following conditions is met:

  • They do not find a CAA RR for your domain.

  • They find a CAA RR for your domain that authorizes them to issue that type of certificate for it.

  • They find only CAA RRs without "issue" or "issuewild" property tags in them for your domain.

The Power of a Single CAA RR

After you create a CAA resource record (RR) to authorize DigiCert to issue SSL/TLS certificates for a domain, you have effectively excluded all other Certificate Authorities (CAs) from issuing a certificate for that domain. The only way to authorize another CA to issue certificates for that domain is to create another CAA RR for that CA.

Note: No CAA RR for the domain means that any CA can issue all types of SSL certificates for it. One CAA RR for the domain means a CA must find a CAA RR that authorizes them to issue that SSL/TLS certificate for the domain. When you create your first CAA RR for a domain, it is important to understand that you must now create enough policies for that domain to support the SSL/TLS certificate requirements of your organization.

In this way, CAA resource records enable precise control over certificate issuance for the domain. This control can be used to prevent unauthorized Certificate Authorities from issuing certificates for your domain.

CA Authorization for DigiCert, Symantec, Thawte, GeoTrust, RapidSSL Brand Certificates

With the recent acquisition of Symantec's Website Security and related PKI solutions, DigiCert brought together the industry’s leading certificate brands under one Certificate Authority – DigiCert. When you create a CAA RR for yourdoman.com and authorize DigiCert to issue SSL/TLS certificates for it (yourdomain.com CAA 0 issue "digicert.com"), you authorize DigiCert to issue DigiCert, Symantec, Thawte, GeoTrust, and RapidSSL brand SSL/TLS certificates for that domain.

The same is true when you create a CAA RR and authorize Symantec to issue SSL/TLS certificates for yourdomain.com (yourdomain.com CAA 0 issue "symantec.com"). This single record enables DigiCert to issue DigiCert, Symantec, Thawte, GeoTrust, and RapidSSL brand SSL/TLS certificates for that domain.

Valid CAA Resource Record Values

Below are valid CAA RR values that you can currently use in your CAA records to authorize DigiCert to issue your SSL/TLS certificate

  • digicert.com

  • www.digicert.com

  • digicert.ne.jp

  • cybertrust.ne.jp

  • symantec.com

  • thawte.com

  • geotrust.com

  • rapidssl.com

All values listed are equivalent. In other words, you can use any one of the values to allow DigiCert to issue SSL/TLS certificates for all the DigiCert certificate brands, portals, products, etc.

Make Sure Your CAA RRs Are Properly Configured

Do you have or are you planning to create DNS CAA RRs for your domains? It's important to ensure that your records are up-to-date and accurate.

At DigiCert, we recommend checking your existing DNS CAA RRs for your domains before you order SSL/TLS certificates for them. Verify you have the necessary records for each CA authorized to issue SSL/TLS certificates for your domains. We also recommend that those creating new DNS CAA RRs understand how the process works. Don't let a misconfigured CAA RR accidentally prevent a CA from issuing a certificate that's needed ASAP.

See How to Edit a Domain's DNS CAA RR to Get DigiCert Certificate Brands.

What is a DNS CAA Resource Record?

Certification Authority Authorization (CAA) resource records (RRs) allow domain owners to create policies that authorize specific Certificate Authorities (CAs) to issue SSL certificates for their associated domains. Domain owners can use CAA RRs to create security policies for an entire domain (e.g., example.com) or for a specific hostname (e.g., mail.example.com).

When you create a CAA RR for your base domain, you are essentially creating an umbrella policy for its subdomains in that policy, unless you create a separate CAA RR for a specific subdomain. Do you have a CAA RR record for example.com) but want to create a different security policy for mail.example.com? Simply create an additional CAA RR specifically for the mail subdomain.

With this record created, when you order an SSL/TLS certificate for mail.example.com, the CA queries your DNS for CAA RRs for that subdomain. If the CA finds a record for mail.example.com, then the search stops, and they apply that policy to the certificate order. If the CA doesn't find a record for mail.example.com, they continue their DNS query for CAA RRs at its parent domain, example.com. If the CA finds a record for the example.com, then they apply the parent domain's policy to the certificate order for mail.example.com.

DNS CAA Resource Record Syntax

A Certification Authority Authorization (CAA) resource record (RR) consists of a single-byte flag and a tag-value pair referred to as a property (RFC 6844 sections 3, 5.1). The flag is an unassigned integer between 0-255. The tag in the tag-value pair may consist of US-ASCII letters and numbers, while the value is an octet string representing the value of the tag-value property.

The CAA RR Property Tags

You can associate multiple properties to the same domain by publishing multiple CAA RRs for that domain name. However, each CAA RR can only authorize one CA to issue certificates (or in some instances one type of certificate) for your domain.

To allow multiple CAs to issue certificates for your domain, you need to create at least one CAA RR for each CA (and in some instances two CAA RRs). For help setting up your CAA RRs, visit CAA Record Helper.

"issue" Property Tag

Use this property tag to authorize a specific CA (such as DigiCert) to issue all types of SSL/TLS certificates for a domain (including Wildcard certificates). To authorize additional CAs to issue all types of certificates for that same domain, create one unique CAA RR for each CA.

For example, to authorize DigiCert to issue DigiCert brand SSL/TLS certificates (DigiCert, Symantec, Thawte, GeoTrust, and RapidSSL) for yourdomain.com, add the following CAA RR (shown in canonical form) to the domain.

yourdomain.com CAA 0 issue "digicert.com"

Limits of the "issue" Property Tag

By default, the "issue" property authorizes a CA to issue both non-Wildcard (domain.com) and Wildcard (*.domain.com) certificates for a domain. However, the authorization power of the "issue" property tag can be limited.

When you create a single "issuewild" CAA RR for yourdomain.com, you effectively remove authorization for Wildcard certificates from all "issue" CAA RRs for other CAs for that same domain. Now an "issue" CAA RR only authorizes other a CAs to issue Standard SSL, EV SSL, Multi-domain SSL, and EV Multi-domain SSL certificates for that domain.

"issuewild" Property Tag

Use this property tag to authorize a CA (such as DigiCert) to issue only Wildcard certificates for a domain. When processing a Wildcard certificate order for *.yourdomain.com, the CA queries the domain's DNS for CAA RRs containing the "issuewild" property tag. If the CA finds an "issuewild" property tag, all CAA RRs with the "issue" property tag for that domain are ignored. To authorize other CAs to issue only Wildcard certificates for the same domain, you will need to create a unique CAA RR for each CA.

yourdomain.com CAA 0 issuewild "digicert.com"

How the "issuewild" Property Tag Works

The "issuewild" property tag authorizes a CA to issue only Wildcard certificates for a domain (*.domain.com, *.sub.domain.com, *.sub.sub.domain.com, etc.). It does not allow a CA to issue non-Wildcard certificates for a domain (domain.com, sub.domain.com, sub.sub.domain.com, etc.).

Using the "issuewild" Properly

When used properly, the "issuewild" property can be an effective tool for creating wildcard certificate issuing policies.

For example, you create three "issue" CAA RRs for yourdomain.com. Later, you decide that you only want one of those CAs to issue Wildcard certificates for yourdomain.com. So, you create an "issuewild" CAA RR authorizing that CA to issue *.yourdomain.com Wildcard certificates. All three CAs can continue to issue non-Wildcard certificates for yourdomain.com, but now only one CA can issue Wildcard certificates for it.

How to Authorize DigiCert to Issue Wildcard Certificates for a Domain

When you order a Wildcard certificate for *.yourdomain.com, DigiCert includes yourdomain.com in the certificate at no extra cost. This poses a problem when you create "issuewild" CAA RRs (yourdomain.com CAA 0 issuewild "digicert.com") to authorize DigiCert to issue only Wildcard certificates for your base and subdomains.

Because we include yourdomain.com (or mail.yourdomain.com) with your Wildcard certificate order for *.yourdomain.com (or *.mail.yourdomain.com), you must use one of the options below so that we can issue your Wildcard certificate to you.

  1. Create an “issue” CAA RR for DigiCert

    Unless you have a specific reason for creating an "issuewild" CAA RR for yourdomain.com, don’t. Managing only "issue" CAA RRs is much simpler:

    yourdomain.com CAA 0 issue "digicert.com"
  2. Create an “issue” CAA RR and an “issuewild” for DigiCert

    If your organization's policies permit it, and you must create “issuewild” CAA RRs for you domain.com, then create two rules:

    yourdomain.com CAA 0 issue "digicert.com"
    yourdomain.com CAA 0 issuewild "digicert.com"
  3. Contact Us

    If your organization's policies prevent you from authorizing DigiCert to issue non-Wildcard certificates for your domain, contact us, and we will work with you to find a solution to the problem so that we can issue your Wildcard certificate.

Improperly Using the "issuewild" Property

When not used properly, the "issuewild" property can effectively block CAs from issuing needed certificates for a domain. When processing certificate orders, CAs ignore all CAA RRs with the "issuewild" property tag, unless (1) the CA is processing an order for a Wildcard certificate, or (2) an "issuewild" tag is the only CAA RR for the domain.

  1. CA Processes Order for Wildcard Certificate

    When you create a single "issuewild" record for your domain (yourdomain.com CAA 0 issuewild "digicert.com"), you effectively exclude all other CAs without an "issuewild" record from issuing a Wildcard for that domain. If that was not your intent when creating the record, then you need to create an additional "issuewild" record for each CA you want authorized to issue Wildcard certificates for yourdomain.com.

  2. "issuewild" CAA RR – Only Type of Record Created for the Domain

    When you order a non-Wildcard certificate for yourdomain.com, the CA will ignore any "issuewild" CAA RRs for the domain, unless the "issuewild" CAA RR is the only type of record found. When this happens, a CA cannot issue a non-Wildcard certificate for yourdomain.com.

    The basic reason to use CAA RRs is to create certificate issuance policies for a domain. When you create a single "issuewild" record for your domain (yourdomain.com CAA 0 issuewild "digicert.com"), without any accompanying "issue" records, you are saying two things:

    1. You authorize this CA (and only this CA) to issue Wildcard certificates for yourdomain.com.

    2. You do not want any CA to issue non-Wildcard certificates for yourdomain.com.

      This is how CAA RRs work and should be your intent when you create only "issuewild" CAA RRs for yourdomain.com.

    When you create that first "issuewild" CAA RR for a domain, it is important to understand that you must now create a policy (CAA RR) for both types of SSL/TLS certificate authorization (non-Wildcard and Wildcard) moving forward.

How CAA RR and CNAME Work Together

When you request an SSL/TLS certificate for a domain (e.g., my.blog.example.com) that contains a CNAME record pointing to another domain (e.g., my.blog.example.net), the Certificate Authority (CA) follows a specific process (laid out in the Baseline Requirements [BRs]) to locate a CAA RR authorizing them to issue your certificate.

CNAME Targets: As a preventative measure against resource exhaustion attacks, a CA is only required to follow up to 8 CNAME targets (8 or fewer CNAME records: blog.example.com is a CNAME for blog.example.net which is a CNAME for blog.example.org and so on 8 levels deep).

The process starts at the domain name on the certificate request and continues to the top-level domain. The process will stop at any point along the way if CAA RRs are found. The CAA RRs then determine whether the CA is authorized to issue your certificate.

DNS CAA Resource Record CNAME Check Flow
 

Note: To see a larger version of the diagram in a new tab, click on the image.

Additional Information: