¶ºÒõ¹Ý

The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certificate authorities (CAs) like ¶ºÒõ¹Ý. This is what browsers use to decide which websites can be trusted and which ones can’t.

But if any CA can issue a TLS/SSL certificate for any domain, certificate issuance could happen without the knowledge of website operators, either by mistake or intentionally by malicious actors. To keep track of which CAs could issue certifications to which organizations, Certification Authority Authorization (CAA) become mandatory in 2017. Of course, with every solution, new challenges can arise. Now, as several problems with CAA checking have arisen, CAs look for a new solution.

In this article, we’ll explain how CAA works, the problems that arose with it, and why RFC 8659-based CAA checking is the next best step forward.

What is Certification Authority Authorization?

A CAA record is a , which allows a domain owner to specify which CAs are authorized to issue certificates for their domain(s) and, by implication, which aren’t.

The idea is that a CA checks the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other authentication checks succeed. However, if it does encounter one or more CAA records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from unauthorized certificate issuance requests by unauthorized parties or bad actors.

So the CA issuance process with CAA checking looks like the following:

CAA checking: mandatory?

¶ºÒõ¹Ý has been checking CAA records for years, but it didn’t become a common practice until 2017, when the CA/Browser Forum passed Ballot 187, requiring all CAs (even those who aren’t a member of the forum) to check for a CAA record as part of the certificate issuance process for each domain. Under , CAs could no longer issue a certificate for a domain unless:

1. The CA does not find any CAA records for the domain
2. The certificate request is consistent with the applicable CAA Resource Record(s)

You can read the ballot in full .

CAA checking: optional?

As one solution brings a new understanding of the problem, new solutions are developed. ¶ºÒõ¹Ý voted in favor of CAA checking becoming mandatory, but since then CAs have run into a variety of problems resulting in errata.

The original RFC specified a search algorithm for CAA that improperly handled CNAME and DNAME CAA records, preventing some organizations that should have been able to obtain certificates from receiving them. In addition, there were a number of errors in the specification of how CAA records should be formatted, as well as a lack of information about what to do if a CAA record exists but does not contain a record listing authorized CAs.

That’s why the Internet Engineering Task Force (IETF) LAMPS working group (of which I serve as co-chair) reviewed these challenges and proposed improvements to replace RFC 6844 with .

RFC 8659 mostly fixes technical errors related to CAA checking. Most certificate users will not notice any changes, since the CA/Browser Forum had already adopted several of the errata. However, RFC 8659 incorporates all these changes into a single, well-written document that describes the proper implementation of modern CAA checking.

An improved process

Our industry is ever-evolving. New technologies and innovations create a need for continual evaluation of policies and processes for ways to improve them. Previous specifications of CAA checking caused some organizations to be denied certificates and left room for error. The newer specification is cleaner and better written, with several problematic corner cases fixed.