CAA Records: Restrict Certificate Issuers Without Breaking Renewals

Web Hosting & Domains / HTTPS / DNS planning

CAA records let you specify which certificate authorities may issue certificates for your domain. Before adding them, inventory every service that obtains certificates for your website, CDN, and subdomains. Then authorize the required issuers, check the effective public DNS answers, and verify the next issuance or renewal through each provider.

A restrictive policy can be useful, but a copied record can block the service that renews your HTTPS certificate. The practical goal is an intentional issuer policy that your actual hosting setup can maintain.

CAA controls issuance, not website traffic

Certification Authority Authorization is a DNS policy checked by certificate issuers. RFC 8659 defines that policy and distinguishes it from a browser validating an already-issued certificate. Changing CAA does not itself revoke existing certificates.

This explains a common operational trap: the site can continue serving HTTPS after a restrictive change while its next certificate request fails. A successful page load immediately after editing DNS is therefore an incomplete check.

CAA also does not prove that the requester controls the domain. AWS Certificate Manager’s setup guidance explicitly separates issuer authorization from domain-control validation. Keep those two checks separate in your plan.

List every service that obtains a certificate

Start with hostnames and service owners rather than with a preferred CA brand. Ask each provider: “Which CAA authorization values and tags does this service require for initial issuance and automatic renewal?” Save the answer with the service name and date.

Include websites that redirect, customer portals, APIs, managed shops, and any wildcard certificates. Also distinguish a CDN’s visitor-facing certificate from the certificate used on the origin server behind it. They can have different issuance arrangements.

Do not infer the complete future issuer list from the certificate currently visible in a browser. That is one deployed certificate, while the service’s documented renewal requirements describe the process you need to preserve.

If the hostname list itself is unclear, our wildcard vs multi-domain certificate guide helps separate coverage requirements from certificate product names.

Read flags, tags, and the issuer value separately

A basic record has a name, the CAA record type, flags, a tag, and a value. Let’s Encrypt’s CAA documentation identifies letsencrypt.org as its issuer value and recommends flags of 0 for the usual configuration.

example.com.  CAA 0 issue "letsencrypt.org"

This hypothetical line illustrates authorizing Let’s Encrypt; it is not a universal configuration to paste into your domain. A DNS dashboard may use separate fields for the name, flags, tag, and CA value. Follow that provider’s input format rather than pasting the whole line into one field.

The issue tag governs ordinary issuance and also wildcard issuance when no applicable issuewild property is present. issuewild provides a separate wildcard authorization rule and takes precedence for wildcard requests. Those relationships are defined in RFC 8659.

For an initial policy, avoid adding unfamiliar critical flags or optional account and validation-method restrictions simply because a generator offers them. Record the reason for every extra restriction and confirm the provider supports it.

Ask for the CA’s documented identifier. The value is not your domain, the hosting company’s marketing name, or a URL copied from a certificate download page.

Check the effective policy for each hostname

Let’s Encrypt explains that a closer CAA record set can override a parent policy and that CAA lookups follow CNAME aliases. A record at the registered domain is therefore not the only place to inspect. Do not add a separate CAA record at a name that already has a CNAME.

Hypothetical planning example: a business uses example.com for its website and app.example.com for a managed portal. The website host confirms one issuer; the portal provider confirms a different requirement. The team should document both workflows before choosing where to place the policies.

Write a desired outcome for each name: which provider must remain able to obtain its certificate, who owns the DNS entry, and how the result will be checked. Then review the proposed records with the relevant providers, especially where aliases or delegated subdomains are involved.

For a certificate containing several names, issuer authorization must be checked for all requested names. A working policy for the root name alone does not establish that a combined certificate request will succeed.

Check the platform’s behaviour before narrowing the list

Some managed certificate services modify the effective policy. Cloudflare documents automatic CAA additions when Universal SSL is enabled and you add CAA records to the zone. These additions preserve its certificate issuance and may be visible in public DNS queries without appearing in the dashboard.

Cloudflare says that automatic behaviour does not apply to Advanced Certificate Manager. Check the documentation for the service you actually use instead of assuming a rule for Universal SSL applies to every certificate product.

For another concrete example, AWS ACM lists several accepted Amazon CA identifiers, including amazon.com. Use its current guidance when building a policy for ACM; a value remembered from another platform is insufficient.

Keep domain validation records intact. ACM’s DNS validation documentation describes CNAME tokens used to establish domain control and support renewal. Adding CAA is not a replacement for those records.

Make the DNS change small and reviewable

1. Save the baseline. Export or record the existing CAA entries, names, tags, values, TTLs, and public answers.
2. Confirm the active DNS provider. Make the change where the domain’s authoritative records are served.
3. Prepare the intended records. Map each authorization to a named certificate service and its documentation.
4. Choose a review window. Leave time to investigate well before certificate expiry.
5. Publish only the planned CAA change. Keep unrelated routing, mail, and DNSSEC edits out of this change.
6. Check public answers and provider status. Save the results and identify the next renewal check.

A useful change note is short: “Added the issuer required by the portal provider; website issuer retained; baseline saved; public answers checked; renewal owner assigned.” This makes a later support request easier to understand.

Keep a recovery action ready. Restoring the previous documented policy is more controlled than deleting records at random. Removing all restrictions is a policy change too, so decide who can authorize it before troubleshooting becomes urgent.

Inspect DNS answers, then verify issuance

On a system with dig installed, use read-only queries like these, replacing the example names. The BIND manual documents dig as a DNS lookup tool.

dig example.com CAA
dig app.example.com CAA
dig app.example.com CNAME

Keep the full response so you can inspect the status as well as the answer section. These queries inspect individual DNS responses; they do not automatically produce a complete certificate-authorization verdict.

Let’s Encrypt notes that CAA queries can fail even when you have not intentionally configured CAA. DNSSEC validation problems and nameserver failures are possible causes. Our DNSSEC validation guide covers the separate signing and delegation checks.

After DNS is correct, use the provider’s supported validation or issuance workflow. Avoid repeatedly forcing production requests while diagnosing. Record a successful issuance or renewal for every affected service, then keep expiry alerts and a named owner in place.

Frequently asked questions