When a CAA Record Blocks Let's Encrypt: What Agencies Should Check Before Renewal

A CAA record Let's Encrypt issue happens when a domain's DNS policy does not authorize Let's Encrypt to issue the certificate being requested. The domain may explicitly authorize a different certificate authority, omit Let's Encrypt from a restrictive policy, or use wildcard-specific issuewild rules that do not match the certificate request.

CAA is not bad. CAA can be a useful guardrail. The risk for agencies is misaligned CAA: an old DNS policy survives a hosting migration, a wildcard rule blocks the new renewal path, or the client owns DNS and nobody checks CAA until renewal fails. Use 47-Day Renewal Pre-Flight to check public CAA-related readiness signals before renewal day, and use the free 10-domain agency audit for broader SSL, DNS, and domain visibility.

CertPilot checks public DNS records as described in its methodology. It surfaces readiness risk, but DNS changes still need to be made by the responsible DNS owner.

Quick answer: how CAA can block Let's Encrypt

CAA records tell certificate authorities which CAs are allowed to issue certificates for a domain. If a domain publishes a restrictive CAA policy and Let's Encrypt is not included, Let's Encrypt may be blocked from issuing or renewing the certificate.

Common blocking patterns include:

• CAA allows only another CA.
• CAA allows an old hosting provider's CA.
• CAA includes issue but not the CA needed by the current platform.
• CAA includes issuewild that blocks wildcard issuance.
• CAA exists at a parent domain and affects subdomains.
• The certificate request changed from non-wildcard to wildcard.

Let's Encrypt publishes practical CAA documentation, and the CAA standard is RFC 8659.

What a CAA record does

CAA stands for Certification Authority Authorization. It is a DNS record type that lets a domain owner say which certificate authorities are allowed to issue certificates for the domain.

In agency terms:

• No CAA record usually means no explicit CA restriction.
• A CAA record can authorize one or more CAs.
• A CAA record can include reporting information.
• A CAA record can distinguish wildcard and non-wildcard issuance.
• Certificate authorities are expected to check CAA before issuing.

CAA is a policy signal. It does not prove domain control, replace ACME validation, or renew certificates by itself. It works alongside validation.

Why CAA matters more when renewal cycles get shorter

Shorter certificate lifetimes increase renewal frequency. A restrictive CAA policy that was hidden for months can become a recurring incident.

For agencies, the issue is timing. CAA problems often surface late:

• The current certificate is still valid.
• The website still loads.
• The client does not know CAA exists.
• The host gives a generic "certificate could not be issued" error.
• The DNS owner is outside the agency.

By the time the browser shows a warning, the team may need DNS access, hosting support, and client approval at the same time. Checking CAA before renewal day reduces that pressure.

The difference between issue and issuewild

The two CAA tags agencies need to understand most often are issue and issuewild.

issue authorizes a CA to issue non-wildcard certificates. For example, it can allow issuance for example.com and www.example.com.

issuewild applies to wildcard certificates such as *.example.com. A domain can allow one CA for normal certificates and a different policy for wildcard certificates.

That distinction matters because a client can appear healthy with a normal certificate while a future wildcard request is blocked. Wildcard renewal risk deserves its own review; see wildcard certificate renewal risks for agencies.

How CAA affects wildcard certificates

Wildcard certificates often rely on DNS-01 validation, and they can also be affected by issuewild CAA rules. This creates two DNS dependencies:

1. The ACME client must be able to publish the DNS validation TXT record.
2. The CAA policy must authorize the CA for wildcard issuance.

If the client owns DNS and the agency owns hosting, this can become an ownership gap. The agency may be responsible for the website outcome without having the DNS access needed to fix the renewal path.

How CAA interacts with DNS control and client-owned domains

CAA is stored in DNS, so the ability to fix CAA depends on DNS ownership. Agencies should document:

• Who controls the authoritative DNS zone.
• Which certificate authority the current host uses.
• Whether CAA is intentionally configured.
• Whether wildcard certificates are used.
• Who can approve CAA changes.
• Whether DNS changes are part of the care plan.

This is why DNS monitoring and SSL renewal operations overlap. If DNS changes unexpectedly, CAA can change too. Read how to monitor DNS changes across client websites for a broader workflow.

Common CAA mistakes agencies see

Common mistakes include:

• Leaving old CAA records after a host migration.
• Copying CAA records from a different domain without checking the issuer.
• Allowing only a paid certificate provider while the new host uses Let's Encrypt.
• Forgetting issuewild when adding a wildcard certificate.
• Adding CAA at the apex without understanding subdomain impact.
• Treating missing CAA as a critical failure.
• Treating any CAA record as proof that renewal will work.

CAA should be reviewed, not feared. A missing CAA record is often acceptable. A restrictive CAA record needs to match the intended renewal path.

CAA pattern table

| CAA pattern | What it allows | What it may block | Agency action | |---|---|---|---| | No CAA record | No explicit CA restriction | Nothing due to CAA specifically | Document as intentionally absent or review | | issue "letsencrypt.org" | Let's Encrypt non-wildcard issuance | Other CAs if they are not also allowed | Confirm current host uses Let's Encrypt | | issue "other-ca.example" only | That CA for normal certificates | Let's Encrypt issuance | Update policy if host uses Let's Encrypt | | issuewild "letsencrypt.org" | Let's Encrypt wildcard issuance | Wildcards from other CAs | Confirm wildcard renewal method | | issue ";" | No CA authorized for that scope | Most issuance | Confirm this is intentional | | Old host CA only | Previous provider issuance | New managed host issuance | Review during migration |

How to check CAA before renewal day

Use this workflow:

1. Identify the domain and all names on the certificate.
2. Confirm the current certificate issuer.
3. Confirm the host, CDN, or ACME client that will renew it.
4. Query public CAA records for the relevant domain.
5. Check whether the policy allows the intended CA.
6. If wildcard names are involved, check issuewild.
7. Document the DNS owner.
8. Confirm who can approve and make changes.

Run Pre-Flight when you want a fast public readiness check for a domain before renewal risk becomes urgent.

CAA troubleshooting checklist

• Does the domain publish any CAA records?
• Does the current host use Let's Encrypt or another CA?
• Does the CAA policy allow that CA?
• Is the certificate wildcard or non-wildcard?
• Is issuewild present?
• Did CAA change during a DNS, CDN, or hosting migration?
• Does the client or agency own DNS?
• Is the CAA decision documented in the client SSL inventory?

If you cannot answer the intended CA question, ask the host or platform. Guessing can create outages.

What to document in a client SSL inventory

Include these fields:

| Field | Example | |---|---| | Domain | example.com | | Covered hostnames | example.com, www.example.com | | Current issuer | Let's Encrypt | | Renewal platform | Managed WordPress host | | CAA state | Allows Let's Encrypt | | Wildcard used | No | | DNS owner | Client IT | | Change owner | Agency technical lead | | Last checked | 2026-05-08 |

The goal is not paperwork. It is faster escalation when a renewal warning appears.

How 47-Day Pre-Flight checks CAA-related risk

47-Day Renewal Pre-Flight checks whether CAA records are present as part of a broader renewal-readiness review. It also checks SSL expiry, DNS basics, port 80 reachability, and HTTP behavior.

Pre-Flight does not edit CAA records or guarantee certificate renewal. It gives agencies a way to surface CAA-related questions earlier: which CA is allowed, who owns DNS, and whether the current certificate setup has obvious public risk signals.

Related 47-Day SSL Resources

• The CAA record gotcha that can break client SSL renewals
• How to test if a host is truly ACME-ready
• HTTP-01 vs DNS-01 for client websites
• Wildcard certificate renewal risks for agencies
• DNS drift guide for agencies

Frequently Asked Questions

What does it mean when a CAA record blocks Let's Encrypt?

It means the domain's DNS policy does not authorize Let's Encrypt to issue the requested certificate. The certificate authority may be able to validate domain control but still refuse issuance because CAA says another CA is allowed, or because wildcard-specific rules do not authorize the request. Agencies should check the CAA policy, intended issuer, and whether the certificate is wildcard or non-wildcard.

Is CAA bad for client websites?

No. CAA is not bad. It can be a useful way to restrict which certificate authorities may issue for a domain. The operational risk is misaligned CAA: a policy that no longer matches the host, CDN, or ACME client responsible for renewal. Agencies should treat CAA as a configuration that needs ownership and documentation, not as something to remove automatically.

Does every website need a CAA record?

No. Many websites do not publish CAA records, and that is not automatically a renewal problem. A missing CAA record usually means no explicit CA restriction. A CAA record becomes important when it is present and restrictive. Agencies should check whether the policy matches the intended certificate authority before renewal day.

What is the difference between issue and issuewild?

issue authorizes certificate authorities for non-wildcard certificates, while issuewild applies to wildcard certificates. A domain can have different policies for normal and wildcard issuance. This matters when a client moves from individual host certificates to a wildcard certificate, or when a wildcard renewal fails even though normal certificates still issue correctly.

Can CertPilot update CAA records?

No. CertPilot does not manage DNS hosting or change DNS records. It helps agencies check public DNS and certificate readiness signals so they can identify CAA-related risk earlier. The DNS owner, such as the client, registrar, DNS provider, or agency technical team, must make any required CAA changes.

Should agencies remove CAA when renewal fails?

Not automatically. Removing CAA without understanding the intended certificate authority can weaken an intentional policy or create confusion across platforms. The safer workflow is to identify the renewal platform, confirm the CA it uses, check wildcard requirements, and update the CAA policy deliberately if the DNS owner approves.