A Call to Reconsider Certification Authority Authorization (CAA)

Certification Authority Authentication (CAA) is a safeguard against illegitimate certificate issuance. We show how shortcomings in CAA concepts and operational aspects undermine its effectiveness in preventing certificate misissuance. Our discussion reveals pitfalls and highlights best practices when designing security protocols based on DNS.

💡 Research Summary

The paper provides a critical reassessment of the Certification Authority Authorization (CAA) mechanism, which was introduced to prevent unauthorized X.509 certificate issuance by allowing domain owners to publish DNS records that specify which Certificate Authorities (CAs) are permitted to issue certificates for their names. The authors begin by outlining the current CAA design as defined in IETF RFC 8657 and mandated by the CA/Browser Forum. In practice, a CA, when processing a certificate request, queries the DNS for CAA records at the exact domain name and, if none are found, walks up the parent hierarchy until a record is encountered or the root is reached. The standard defines several tags—issue, issuewild, iodef, contactemail, contactphone—and a “critical” flag that forces a CA to reject a request if an unsupported critical tag is present.

The core contribution of the paper is the identification of four systemic weaknesses that undermine CAA’s effectiveness: (1) Implicit semantics – the same syntactic construct can express contradictory policies (e.g., an empty “issue” tag is meant to forbid issuance, yet many implementations treat it as a no‑op). This ambiguity makes it impossible for CAs to differentiate between intentional configurations and accidental typos. (2) Underspecified syntax – the specification does not enforce a unique format for CA identifiers, allowing malformed or misspelled values (e.g., “0issueletsencrypt.org” or “isssue”) to be interpreted as valid, which can unintentionally lift restrictions. (3) Boundless policy scoping – CAA records are inherited from parent zones, breaking the DNS delegation authority model. Consequently, a child zone that does not publish its own CAA record is governed by the parent’s policy, exposing it to attacks that compromise or spoof upstream name servers. The problem is amplified for CNAME aliases, where only the canonical name’s CAA record is consulted. (4) Misaligned procedures – CAA records are unsigned and lack a validity period, so they can be altered after a certificate has been issued, rendering them useless for forensic audits. Moreover, CAs are not required to retain the DNSSEC validation chain used during issuance, which hampers accountability.

To substantiate these claims, the authors performed a large‑scale measurement campaign using Certificate Transparency (CT) logs. Over a two‑week window in June 2024 they harvested more than 5.4 million certificates from ten active CT logs operated by five companies. After de‑duplicating, 4.6 million unique certificates remained. For each certificate they extracted every DNS name in the Subject Alternative Name (SAN) field, expanded each name to all its parent zones (e.g., www.example.co.uk → www.example.co.uk, example.co.uk, co.uk, uk), and performed authoritative DNS queries for CAA records at each level. They deliberately avoided recursive resolvers to eliminate cache‑stale data. The resulting dataset linked 5.8 million distinct domain names (34 % of which were wildcards) to the CAA records observed at issuance time.

The empirical analysis uncovered concrete instances of the identified weaknesses: 811 certificates were issued despite an empty “issue” tag, 18 records combined malformed values with valid identifiers, and 1,319 domains used the malformed identifier “0issueletsencrypt.org”. Additional errors included misspelled tags such as “isssue” that caused CAs to ignore the intended restriction, and a real‑world bug in GoDaddy’s validation logic that allowed issuance for fully qualified domain names even when a restrictive “issuewild” was present. These findings demonstrate that the specification’s tolerance for ambiguous input directly translates into operational misconfigurations.

The paper concludes with a set of concrete recommendations: (1) Semantic clarification – each tag should have a single, well‑defined meaning; “no‑issue” policies should be expressed with a standardized sentinel value (e.g., a solitary semicolon) rather than an empty or malformed string. (2) Scope confinement – either tighten the lookup algorithm to stop at the authoritative zone of the queried name or introduce a dedicated sub‑domain (e.g., _caa.example.com) that isolates CAA records from parent inheritance. (3) Centralized CA identifier management – allocate CA identifiers through a coordinated registry (such as IANA) and publish a public index so domain owners can reliably select the correct identifier. (4) Mandate DNSSEC – require that CAA lookups be performed over DNSSEC‑validated responses and that CAs retain the full DNSSEC validation chain in their issuance logs, thereby enabling reliable post‑mortem audits. (5) Integration with CT – leverage CT logs to automatically detect CAA violations and enforce penalties on non‑compliant CAs, strengthening the overall accountability ecosystem.

By addressing these design and operational gaps, the authors argue that CAA can regain its intended role as a proactive barrier against certificate mis‑issuance while complementing other transparency mechanisms such as Certificate Transparency. The paper thus provides both a diagnostic of current shortcomings and a roadmap for evolving CAA into a robust component of the web PKI security stack.