20170413 - CA/B Forum makes CAA checking mandatory for Certification Authorities

As of 8 September 2017, each certifying authority will have to control the CAA DNS records before issuing an SSL certificate. Although already existing for a while the CAA control has been optional, today the authority can choose to carry out this control or not.

Caution: This check must then be carried out for each of the SANs to be secured by the requested certificate.

What is CAA?

The CAA (for Certificate Authority Authorisation) is a DNS record allowing the owner of a domain name to authorize (and therefore also prohibit) one or more certification authorities to issue certificates for the domain concerned.

How does it work?

The DNS CAA specification is not mandatory and if no registration is defined for a domain then it is assumed that permission is tacitly given to all Certification Authorities to issue for that domain.

On the other hand an empty entry means a global interdiction.

NOTE : Une fois le certificat émis le contrôle CAA n'est plus utile. Les tierce parties (navigateurs par exemple) ne vérifient pas le DNS CAA lorsqu'un certificat est sollicité. En effet, il se peut que l'enregistrement ai été modifié après une émission, sans invalider un certificat.

What is the use of such a control?

It gives you the ability to prohibit certificate authorities from issuing certificates on your behalf. You then have better control of your SSL tools.

It can also be seen as an additional audit step enabling the authority to reduce the risk of unwanted emissions.

And in practice?

CAA handles several properties:

• issue: contains authorization/restrictions regarding the concerned domain
  If this property is used alone, it is valid both for the domain concerned and for Wildcard certificates.
  Here is an example:

  example.com. CAA 0 issue "sectigo.com"

  Authorization for Sectigo to issue certificates for example.com and Wildcard certificates for *.example.com


• issuewild: contains the authorizations/restrictions for the domain concerned. This property is specific to wildcard certificates. If it does not exist then it is the property issue which will be used for wildcard certificates (the reverse is not true)
  Here is an example:

  example.com. CAA 0 issuewild "sectigo.com"

  Authorization for Sectigo to issue certificates for *.example.com only


• issuevmc: contains the authorizations/restrictions for the domain concerned. This property is specific to VMC certificates. If it does not exist then it is the property issue which will be used for VMC certificates (the reverse is not true)
  Here is an example:

  example.com. CAA 0 issuevmc "digicert.com"

  Authorization for DigiCert to issue VMC certificates for *.example.com only


• issuemail: contains the authorizations/restrictions for the domain concerned. This property is specific to S/MIME certificates. If it does not exist then there is no restriction
  Here is an example:

  mail.example.com     CAA 0 issuemail "sectigo.com"

  Authorization for Sectigo to issue S/MIME certificates for mail.example.com only


• iodef (Incident Object Description Exchange Format) : indique une URL permettant de rapporter des problémes rencontrés lors de la procédure d'audit. Le format de l'URL indique la méthode qui devra être utilisée (mailto pour un envoi de mail ou http pour l'utilisation d'un webservice).

Other values can be added at the discretion of the domain owner or at the request of the certification authority.

What about sub-domains?

It is possible to create CAA DNSs specific to sub-domains rather than an entire domain. In this case, the authority will first look for a DNS CAA record for the sub-domain and then, if none exists, for the root domain.

Case of CAA with CNAME value

It is possible that in your internal DNS configuration, a record points to another domain for which you have requested a certificate.

Example: you request a certificate with the CN: domain1.fr. This domain contains a CNAME record pointing to domain2.fr. In this kind of case, the authority follows a specific procedure (defined by the CA/B Forum)

1. The authority go to domain1.fr (CN of the certificate).


2. Check if a CAA record is present or not in the domain's DNS zone.


3. If a CAA record is present:
   • the registration authorizes the issuance of the certificate => the generation of the certificate can be done.
   • the recording does not allow transmission: order stop.


4. If a CAA record is not present, we go to the next step.


5. The authority checks if a CNAME record for domain1.fr is present:
   • if a CNAME is present, the authority will search if a CAA record is present (from point 2)
   • if there is no CNAME, the authority checks the parent domain (if existing).

To summarize, the CAA check is done on each domain level and if a CNAME is present, the check will also be done at that level. As soon as a CAA record is detected, the verification stops.

issue and issuewild values

In the table below you'll find the values  to be defined for issue and issuewild for each certifying authority :

* Values updated on 2021-12-29

How to define several authorizations?

If you wish to authorize more than one certification authority then you need to multiply the CAA registrations.

Example:

example.com.  CAA 0 issue "sectigo.com"
example.com.  CAA 0 issue "globalsign.com"

CAA control for S/MIME certificates

As of September 15, 2024, Sectigo has begun enforcing CAA lookups for S/MIME certificates.

Useful links

• RFC 6844
• Ballot 187 of the CA/B Forum making CAA control mandatory
• issue and issuewild value
• CAA test tool
• Digicert documentation on the CAA
• Sectigo documentation about CAA