CA/B Forum ballot · Ballot 187
Ballot 187: CAA checking becomes mandatory for every CA
Details
- Ballot
- Ballot 187
- Title
- Make CAA Checking Mandatory
- Status
- Passed
- Date
- 2017-03-08
- Adopted
- Effective
- BR version
- 1.4.3
- Official page
- cabforum.org
Key dates
- CAs must check CAA records and refuse issuance when CAA doesn't authorize them
Ballot 187 is why CAA records work. Since 2017-09-08 every publicly trusted CA must look up a domain's CAA records before issuing a certificate and must refuse if the records don't authorize it, so a domain owner can limit issuance to the CAs they actually use.
What changed
Ballot 187 turned CAA checking from optional into mandatory. CAA was defined in RFC 6844 in January 2013 (since replaced by RFC 8659), but optional checking made it nearly useless: a record only protects you if every CA honors it. The intent, in the ballot's words, was to make CAA checking mandatory at issuance for all certificates except a few special cases, and to prevent issuance if a CAA record doesn't permit that CA. CAs also had to state their CAA policy and the domains they recognize in their CP/CPS. Gervase Markham of Mozilla proposed it, with DigiCert and Google endorsing.
Effective dates
The ballot passed on 2017-03-08 with 94% of voting CAs and 100% of voting browsers in favor. CAA checking became mandatory on 2017-09-08.
Who is affected
Domain owners gained a free way to restrict which CAs may issue for them. Anyone who publishes CAA must keep it up to date: a CAA record that doesn't list your current CA causes issuance and renewal to fail.
What to do
Publish CAA records naming the CAs you use, for example example.com. CAA 0 issue "letsencrypt.org", and add an issuewild entry if you use wildcards. Check your setup with the CAA checker or build records with the CAA generator. SC-098v2 adds account and method restrictions from 2027.