Certificate authorities will verify your identity before issuing or renewing certificates (and so will Imperva).
Certificate authorities are required by the CA/Browser Forum to verify your identity before issuing or renewing certificates. The verification is done using the DNS Certificate Authority Authorization (CAA) Record which serves as a certificate control policy. This additional verification process between the CA and DNS entities limits the ability of an attacker to issue certificates for your site and execute attacks such as Man in the Middle (MITM). In this post, we’ll look at how CAA records add an extra layer of security against fraudulent and malicious activity.
What is a CAA record and why is it important?
RFC 6844 (2013) defines and specifies the DNS CAA record. It is intended for use by domain owners as a control policy to specify which CAs are authorized to issue certificates for their domain.
CAA records are not mandatory (for now?), but the CA/B Forum recommends using it and so do we. Using CAA records help domain owners limit the CAs that can issue certificates for their domain, and can prevent unauthorized, fraudulent, or malicious issuing of certificates.
According to the requirement, a CA can issue a certificate for domains with one of the following:
- No CAA records
- A CAA record that names the specific CA
If your DNS zone file currently contains CAA records, but does not contain a record for the CA you are requesting a certificate from and if that CA has implemented CAA validation, then that CA cannot issue or renew a certificate for your domain. Moreover, CAs are permitted to treat a record lookup failure as permission to issue if the failure is outside the CA’s infrastructure, or the lookup has been retried at least once or the domain’s zone does not have a DNSSEC validation chain to the ICANN root.
CAA records can be defined for an entire domain or for specific hostnames. In the former case, sub-domains inherit the CAA policy of the root domain, unless overridden.
The CAA record includes three elements: flags, tag and value.
The canonical representation:
CAA <flags> <tag> <value>
The flag is an unsigned integer between 0-255. The tag is an ASCII string that represents the identifier of the property represented by the record. Finally, the value is associated with the tag, and is the string that represents the CA’s name.
CAA 0 issuewild “globalsign.com”
Making CAA checking mandatory
On March 8, 2017, the CA/B Forum approved Ballot 187 making CAA checking mandatory, effective September 8, 2017. The motion was proposed by Mozilla and endorsed by Google. Approving the ballot mandates all certificate authorities to check for CAA records before issuing or renewing certificates.
A total of 22 certificate authorities and browser vendors participated in the ballot. The motion passed with 100 percent of browser vendors and 94 percent of the certificate authorities voting in favor.
|Voting by Browsers||Mozilla, Google, Apple||–||–|
|Voting by CAs||Let’s Encrypt, Izenpe, Comodo, GoDaddy, HARICA, GDCA, Trustwave, SwissSign, Symantec, SHECA, CFCA, SSC, GlobalSign, Cisco, Bypass, DigiCert, Disig||Sertifitseerimiskeskus||Actalis|
How does this affect the Incapsula service?
If you have an Enterprise, Business or Pro account, when you onboard a new SSL/TLS site to the Incapsula service, or enable SSL/TLS for an existing site using Incapsula generated certificates, the service will automatically check for CAA compliance (see the next section for details on what we’ve defined as “CAA compliant”) to ensure the successful issuing of certificates.
When your certificate approaches its renewal date, Incapsula will check for CAA compliance and notify you beforehand, allowing you sufficient time to make changes, if needed. Routine compliance checks are also run automatically regardless of your certificate’s or SAN’s expiration dates.
In compliance with the CAA changes, Imperva will not issue or renew a certificate or SAN value for a non-CAA compliant domain because they do not meet the requirements of the certificate authorities.
What do I need to do?
If you use an Incapsula-generated certificate, in order to be CAA compliant, create non-wildcard CAA records for GlobalSign and Comodo, Incapsula CA partners, in your DNS zone file. You can use this third-party tool to generate a CAA record. Incapsula will check your site, and climb recursively to the root domain if no CAA record has been found for a sub-domain (according to the RFC). For more instructions, read our documentation. Another option is to leave your DNS zone file CAA-record-free, but we recommend configuring the records. If you do decide to create the records, be sure to create both.
To check if your site is CAA compliant, you can test it directly from the management console (Site Settings > General > SSL Settings), use a third-party tool or run a query using the dig CAA tool:
$ dig incapsula.com type257
If you use a custom certificate, even though the Incapsula service will not check for CAA records in this case, your CA will probably implement the check if they haven’t already. Therefore we do recommend that you use CAA records.
What’s the CA/Browser Forum?
The Certificate Authority and Browser Forum (AKA CA/B Forum) is a consortium of certificate authorities, browser vendors, operating system vendors, and other relevant application vendors such as Microsoft, Apple, GlobalSign, Comodo, GoDaddy, and others.
The forum was founded in 2005 to the purpose of establish an industry standard for the issuance and management of publicly-trusted SSL/TLS certificates by certificate authorities, browsers, and other relevant applications. These standards are defined by the forum as baseline requirements (BR). As part of this effort, new requirements are published periodically and then approved by the consortium members. These requirements serve as the minimal standard for CAs and browsers.