What is an example of Certificate Authority Authorization (CAA) in practice?

What CAA looks like in a real domain setup

A practical CAA example is a domain owner publishing a DNS policy that only allows one or two named certificate authorities to issue certificates. If a CA later sees that record, it should only proceed when it is on the authorised list. That makes CAA a preventive control, not a guarantee, and it works best when certificate issuance is tightly managed.

For example, a company might allow only a primary commercial CA and a backup CA for example.com, while denying issuance from everyone else. The policy can also be scoped to specific certificate types, so the organisation can treat the main website, mail services, and internal subdomains differently.

How CA checks the record before issuing

CAA is enforced during certificate request processing. The CA queries DNS for the domain, evaluates the applicable CAA record set, and checks whether the requested issuance matches the policy. If the CA is not authorised, or if the request conflicts with the record's restrictions, it should refuse issuance rather than treating the request as a normal order.

That means the protection depends on two things: the domain owner publishing the right policy, and the CA respecting it. CAA is especially useful for reducing accidental issuance by a legitimate CA and for narrowing which trust relationships can produce a publicly trusted certificate.

Domain owners often pair CA/Browser Forum issuance expectations with DNS policy so that certificate requests are not left to provider defaults. For certificate lifecycle planning, the issuance control should sit alongside rotation and cryptographic housekeeping, not replace them, which is why teams also track NIST SP 800-57 Key Management when they manage keys and certificate-related material over time.

What this means operationally for security teams

In practice, CAA helps security teams reduce unauthorised certificate issuance, but it does not stop every certificate problem. If the wrong CA is authorised, if DNS is misconfigured, or if a subdomain inherits the wrong policy, issuance can still happen. The control is most effective when the organisation knows which business units, service owners, and external providers are allowed to request certificates.

Teams should also remember that CAA is only one layer in the certificate lifecycle. The operational question is not just "Can this CA issue?" but also "Who owns the domain, who can change DNS, and how quickly can we detect unwanted issuance?" Those questions become more important when certificates are provisioned automatically for many services or subdomains.

When certificate ownership and renewal are spread across multiple systems, it is useful to centralise lifecycle visibility in a Machine Identity, PKI and Certificate Lifecycle Guide, because CAA only answers the issuance-authorisation part of the problem. If your environment has many service endpoints or automation paths, the broader NHI Lifecycle Management Guide is useful for thinking about provisioning, rotation, and offboarding as one control chain rather than separate tasks.

When certificate policy spans services, keys, and trust boundaries, IAM and IGA Basics is a useful reference for understanding ownership, review, and entitlement-style governance around who may create or change security-relevant resources.

Risk and Threat Considerations

CAA reduces the risk of accidental or unauthorised issuance, but it does not eliminate exposure if DNS is weakly governed or if an attacker can alter zone records. It is also limited by CA compliance, so organisations should treat CAA as a narrowing control, not a complete certificate security boundary.

Failure mechanism: If an attacker, compromised administrator, or misconfigured automation changes the DNS record, the organisation may silently authorise an unwanted CA or widen issuance scope. If the CA ignores or mishandles the policy, the intended control fails even when the record is present.

Impact: Unauthorised certificates can support phishing, traffic interception, brand impersonation, or trust abuse against users and downstream services. In a weakly monitored environment, the first sign may be certificate transparency evidence or unexpected certificate deployment, rather than an obvious outage.

Practitioner Guidance

What to verify: Confirm which domains and subdomains actually have CAA records, which CAs are authorised, and whether wildcard or service-specific rules match your intended issuance model. Also verify that DNS change control is restricted, because a sound policy is ineffective if anyone can rewrite it.

Decision rule: If a certificate is being requested for a production domain and the requesting CA is not explicitly authorised, treat that as a stop condition until the policy is corrected or the exception is approved. If certificate issuance is automated, make the policy part of the deployment design rather than a manual afterthought.

Practitioner takeaway: CAA is best treated as a domain-level guardrail for certificate issuance, most valuable when it is paired with strong DNS governance, ownership clarity, and monitoring for unexpected certificate activity.

Related resources from NHI Mgmt Group

• What are common mistakes with Certificate Authority Authorization (CAA)?
• Certificate Authority Authorization (CAA)
• What is an example of SAML Signing Certificate in practice?
• What is an example of a soft certificate in practice?