Current CA / B Forum approved regulations state that certifying authorities must ensure that requests for SSL certificates received either from domain owners themselves or from those who is in charge of managing this domain. Generally, domain name verification done by creating a DNS TXT record with a specific value or by loading code to a specific location of the site. This confirms the fact of domain ownership.
At the same time, hacking website allow attackers to pass through validation checks and get a trusted certificate for compromised domain from any certification authority. This certificate could be used for man-in-the-middle attacks or for redirecting users to a phishing pages. CAA introduction allows coping these fraudulent activities.
What is CAA?
CAA (Certification Authority Authorization) is a unique DNS record, which was accepted as a standard for the industry in 2013, however was optional since then. Due to this record, domain owners are able to specify the certification authorities that are permitted to issue SSL / TLS certificates for the specified domains.
The CAA record allows avoiding unauthorized SSL- certificates issuance, in error or with intentional purposes - for phishing, various attacks, etc.
The purpose of introducing a CAA entry is to restrict the list of certifying authorities that can issue certificates for a domain.
The structure of the CAA is as follows:
FQDN CAA flags property value
Example: search.com 86400 IN CAA 0 issue "comodo.com"
This entry states that for the domain search.com only the Comodo certification authority permitted to issue SSL-certificates.
To allow issuing only wildcard certificates for a domain, the following CAA record (with the issuewild property) is applied:
example.org. CAA 0 issuewild certificate_authority.com
The Ballot 187 proposal from the CA / B Forum sets mandatory CAA verification for all CAs
Recently, CA / B Forum adopted the Ballot 187, which makes CAA verification mandatory standard for all certification authorities. For the proposal voted 17 certifying authorities (94%) and 3 browser manufacturers (100%). The proposal will come into force on September 8. If the certifying center postpone accepting these rules, it will cause bad consequences such as sanctions applied against it by CA / B Forum.
In addition to the “issue” tag, an “iodef” tag will also become mandatory attribute, which would need to be used in the CAA entry by certification authorities. This tag allows specifying an email or URL for communication with the domain owner - this would help sending reports about all requests for certificates for this domain that will contradict with the CAA policy. The domain owner will be aware that someone tried to get a certificate for their domain without proper authorization and will have an opportunity to take appropriate protective measures.
An example of a CAA record with a specific iodef:
Example.org. CAA 0 iodef mailto: firstname.lastname@example.org
Example.org. CAA 0 iodef https://site.example.org/
Current issues with implementation of CAA
The mandatory CAA verification still have some undefined issues. First, there is no clear policy on how exactly CAA verification will work with CNAME records stored in CAA. If two certifying authorities are set as permitted issuers in the certificate, it becomes unclear who exactly controls its issuance.
Secondly, there is no software that would support CAA at the DNS and CA level. This will be a major blow for small certification authorities, since they may not have time to acquire proper tools by September.
Although CAA is relatively new to DNS, it could be easily implemented using a modern infrastructure. The lack of CAA support from third-party DNS providers can be a problem for certain organizations. However, there is still a lot of time until September, and therefore the certifying authorities and all the other involved parties will have time to adopt these new requirements.