Public certificate authorities validate control of a domain name before issuing a certificate, but domain control is not the only policy a domain operator can publish. Certificate Authority Authorization (CAA), specified in RFC 8659, adds a DNS-based signal that states which CAs are permitted to issue for a name.
CAA does not replace domain-control validation. It adds another decision point before issuance: a conforming CA checks the applicable CAA policy and proceeds only when that policy permits the CA to issue the requested certificate.
A CAA record expresses issuance policy
A CAA resource record has a flags field, a property tag, and a property value. A simple record can authorize one CA:
example.com. CAA 0 issue "ca.example"The issue property authorizes the identified CA to issue certificates for the domain, subject to the CA’s normal validation and issuance requirements. Multiple issue records can authorize multiple CAs; authorization is not limited to a single record.
An empty issue value can explicitly deny issuance through that property:
example.com. CAA 0 issue ";"Operational configurations need to reflect every CA that is legitimately expected to issue. Omitting a required CA can turn a security control into an availability problem when renewal or emergency replacement is attempted.
Wildcard issuance has a separate control
CAA defines issuewild for wildcard certificates. This permits a domain to express a wildcard issuance policy separately from ordinary issuance.
For example:
example.com. CAA 0 issue "ca.example"
example.com. CAA 0 issuewild "wildcard-ca.example"This policy can authorize different CAs for ordinary and wildcard certificates. The distinction matters because wildcard issuance can use different operational workflows and validation methods from non-wildcard issuance.
If no relevant issuewild property is present, the applicable issue properties also govern wildcard issuance. Adding issuewild creates the separate wildcard policy.
Policy lookup can inherit from a parent name
CAA processing does not require a record at every hostname. When a name has no applicable CAA record set, lookup can continue through its DNS ancestry according to the CAA processing rules.
A policy at a registered domain can therefore cover subordinate names unless a more specific applicable policy changes the result. This is useful for centralized issuance policy, but it also means delegated or independently operated subdomains need deliberate treatment.
CNAME processing also matters. CAA evaluation follows the rules defined for aliases and the relevant DNS names, so operators should inspect the effective DNS path rather than assuming that only the visible hostname contributes policy.
The critical flag changes handling of unknown properties
The flags octet includes an issuer-critical bit. When that bit is set on a property that a CA does not recognize, the CA must not issue on the basis of a record set it cannot correctly process.
A record can therefore mark a property as critical:
example.com. CAA 128 custom-property "value"Using the critical bit requires care. An unsupported critical property can intentionally stop issuance, but an accidental or poorly coordinated deployment can also block legitimate certificate operations.
The flag does not make a known property stronger. Its purpose is to control behavior when the property tag is not recognized.
CAA constrains issuance, not certificate use
CAA is checked in the certificate issuance process. Browsers do not use CAA as a replacement for normal certificate path validation, hostname checks, validity periods, revocation mechanisms, or other TLS verification rules.
A certificate that already exists is not invalidated merely because the domain later changes its CAA records. The new policy affects subsequent issuance decisions made under the applicable CAA requirements.
This timing distinction is important during CA migration. Changing DNS policy and replacing existing certificates are separate operations.
DNS integrity sets the strength of the signal
CAA is carried in DNS. Without DNSSEC validation, DNS responses do not gain cryptographic origin authentication from CAA itself. An attacker able to alter relevant DNS answers may be able to interfere with the policy seen by a CA, depending on the attack position and the CA’s resolution path.
DNSSEC can authenticate DNS data when the chain of trust validates, but CAA and DNSSEC serve different roles. CAA states issuance policy; DNSSEC can protect the authenticity and integrity of the DNS data carrying that policy.
CAA should therefore be treated as one control in certificate issuance governance, not as a standalone guarantee against every form of misissuance.
Operational changes need renewal-path testing
Certificate automation often runs quietly until renewal fails. A CAA change should be checked against the actual CA identifiers, wildcard requirements, DNS delegation, aliases, and automation accounts used in production.
Some CAs support additional CAA parameters under their documented practices, but those parameters are CA-specific and should not be assumed to have universal semantics. Configuration should follow the documentation of each authorized CA.
The durable value of CAA is narrow and concrete: it lets a domain publish an issuance boundary in DNS. That boundary is most effective when the authorized CA set is kept small, the effective DNS policy is observable, and certificate renewal paths are tested before existing certificates approach expiration.