DNS CAA resource record check

Certificate authorities are required to check the CAA resource records prior to issuing certificates

Before a Certificate Authority (CA) can issue a TLS/SSL 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.)

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

  • Have CAA resource records set up for your domains
  • Plan 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

Before issuing a TLS/SSL certificate for a domain, a CA (such as DigiCert) checks the domain’s CAA RRs to verify that they are authorized to issue that certificate. A CA can issue a certificate for a 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 authorizing them to issue that certificate.
  • They only find CAA RRs for your domain without the "issue" or "issuewild" property tags.

Power of a single CAA RR

After creating a CAA resource record (RR) that authorizes DigiCert to issue TLS/SSL certificates for a domain, you have effectively deauthorized 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.

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

If you don’t have a CAA RR for your domain, then any CA can issue TLS/SSL certificates for it.

If you have one CAA RR authorizing a specific CA to issue certificates for your domain, then all other CAs must find a CAA RR that specifically authorizes them to issue a TLS/SSL certificate for it. If they don’t find one, they cannot issue the certificate.

Remember, when using CAA RRs for your domains, to create enough CAA RRs to support your organization's TLS/SSL certificate requirements.

CA authorization for DigiCert, Thawte, GeoTrust, and RapidSSL brand certificates

With the 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 creating a CAA RR for yourdoman.com that authorizes DigiCert to issue TLS/SSL certificates for it (yourdomain CAA 0 issue "digicert.com"), you authorize DigiCert to issue DigiCert, Thawte, GeoTrust, and RapidSSL brand TLS/SSL 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 TLS/SSL certificate:

  • digicert.com
  • www.digicert.com
  • digicert.ne.jp
  • cybertrust.ne.jp
  • thawte.com
  • geotrust.com
  • rapidssl.com
  • volusion.digitalcertvalidation.com
  • stratossl.digitalcertvalidation.com
  • intermediatecertificate.digitalcertvalidation.com
  • ​1and1.digitalcertvalidation.com

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

Verify your CAA RRs are properly configured

Do you have or are you planning to create DNS CAA RRs for your domains? Make sure that your records are up-to-date and accurate.

DigiCert recommends checking your domains' existing DNS CAA RRs before you order TLS/SSL certificates. Verify that you have the records for each CA authorized to issue TLS/SSL certificates for your domains. We also recommend understanding the process before creating new DNS CAA RRs for a domain. Don't let a misconfigured CAA RR accidentally prevent a CA from issuing a certificate needed as soon as possible.

See Edit the CAA resource record to authorize DigiCert to issue certificates for your domain.

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 TLS/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 a specific hostname (e.g., mail.example.com).

When you create a CAA RR for your base domain, you create 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 for example.com but want to create a different security policy for mail.example.com? Create an additional CAA RR specifically for the mail subdomain.

With this record created, when you order a TLS/SSL 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 example.com, 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.

CAA RR property tags

You can associate multiple properties with 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 (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 CA (such as DigiCert) to issue certificates for yourdomain and *.yourdomain. When processing a certificate order for yourdomain or *.yourdomain, the CA queries the domain's DNS for CAA RRs containing the "issue" property tag. If the CA finds only an "issue" property tag and that tag that authorizes them to issue a certificate for the yourdomain, they can issue a certificate for yourdomain and *.yourdomain.

To authorize multiple CAs to issue certificates for yourdomain and *.yourdomain, you must create a unique CAA RR for each CA.

generic
yourdomain CAA 0 issue "digicert.com"
yourdomain CAA 0 issue "ca2.example.com"

"issuewild" property tag

Use this property tag to authorize a CA (such as DigiCert) to issue a certificate for *.yourdomain. When processing a certificate order for *.yourdomain, the CA queries the domain's DNS for CAA RRs containing the "issuewild" property tag.

  • If the CA finds an "issuewild" property tag, they check to see if it authorizes them to issue a certificate for *.yourdomain.
  • If the CA doesn’t find an "issuewild" property tag, they look for an “issue” property tag authorizing them to issue a certificate for yourdomain and *.yourdomain.

To authorize multiple CAs to issue certificates for *.yourdomain, you must create a unique CAA RR for each CA.

generic
yourdomain CAA 0 issuewild "digicert.com"
yourdomain CAA 0 issuewild “ca2.example.com”

How the "issuewild" property tag works

The "issuewild" property tag authorizes a CA to issue a certificate for a *.yourdomain, *.sub.yourdomain, *.sub.sub.yourdomain, etc. It does not specifically authorize or prevent a CA from issuing a certificate for yourdomain, sub.yourdomain, sub.sub.yourdomain, etc.

Using the "issuewild" property tag

When correctly used, the "issuewild" property can be an effective tool for creating certificate issuance policies.

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

Authorize DigiCert to issue wildcard certificates for a domain

When you order a certificate for *.yourdomain, DigiCert includes yourdomain in the certificate at no extra cost. This poses a problem when creating “issue” and “issuewild” CAA RRs for your domains using multiple CAs.

For example, DigiCert includes yourdomain with your certificate order for *.yourdomain. Therefore, if you authorize multiple CAs to issue certificates for yourdomain, use one of the options below so that DigiCert can issue your certificates.

  1. Only use the “issue” property tag and create an “issue” CAA RR for DigiCert

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

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

    If organization policy permits it and you must create separate CAA RRs for yourdomain and *.yourdomain.com, create two rules:

    • One authorizing DigiCert to issue certificates for yourdomain
    • One authorizing DigiCert to issue certificates for *.yourdomain
generic
yourdomain CAA 0 issue "digicert.com"
yourdomain CAA 0 issuewild "digicert.com"
  1. Contact Us

    If organization policy prevents you from authorizing DigiCert to issue certificates for yourdomain, contact us. We will work to find a solution to the problem so we can issue your certificate for *.yourdomain.

How CAA RR and CNAME work together

When requesting a TLS/SSL 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, eight 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 determine whether the CA is authorized to issue your certificate.

Example of CAA RR check workflow with CNAME present

Step 1: CA checks the CAA RRs for the domain name on the certificate request–my.blog.example.com

The search stops if the CA finds a CAA record for the domain on the certificate request. The CA checks to see if a CAA record authorizes them to issue your certificate. If they find the record, the CA issues the certificate. If they don't find the record, the CA cannot issue the certificate.

If the CA doesn't find a CAA record for the domain on the certificate request, the CAA record search continues.

Step 2: CA checks the CAA RRs for the CNAME target domain–my.blog.example.net

The search stops if the CA finds a CAA record for the CNAME target domain. The CA checks to see if a CAA record authorizes them to issue your certificate. If they find the record, the CA issues the certificate. If they don't find the record, the CA cannot issue the certificate.

If the CA doesn't find a CAA record for the CNAME target domain, the CAA record search continues.

Step 3: CA checks the CAA RRs for the original domain's parent domain–blog.example.com

The search stops if the CA finds a CAA record for the original domain's parent domain. The CA checks to see if a CAA record authorizes them to issue your certificate. If they find the record, the CA issues the certificate. If they don't find the record, the CA cannot issue the certificate.

If the CA doesn't find a CAA record for the original domain's parent domain, the CAA record search continues.

Step 4: CA checks the CAA RRs for the original domain's base domain–example.com.

The search stops if the CA finds a CAA record for the original domain's base domain. The CA checks to see if a CAA record authorizes them to issue your certificate. If they find the record, the CA issues the certificate. If they don't find the record, the CA cannot issue the certificate.

If the CA doesn't find a CAA record for the original domain's base domain, the CAA record search continues.

Step 5: CA checks the CAA RRs for the original domain's top-level domain–com.

The search stops.

  • If the CA finds a CAA record for the original domain's top-level domain. The CA checks to see if a CAA record authorizes them to issue your certificate. If they find the record, the CA issues the certificate. If they don't find the record, the CA cannot issue the certificate.
  • If the CA doesn't find a CAA record for the original domain's top-level domain, the CA issues the certificate.

Additional information: