Fixing CAA Failures When Switching from Manual SSL to ACME Clients

Switching a production domain from manual certificate renewals to an automated ACME client should be routine. You point Certbot, acme.sh, or your hosting control panel's AutoSSL tool at the domain, complete the HTTP-01 or DNS-01 challenge, and wait for the web server to reload with the new certificate. Instead, the ACME order halts at the final authorization phase with an error stating that the certificate authority is not permitted to issue certificates for your domain name. This failure happens frequently when migrating domains that previously relied on commercial, manually ordered SSL certificates. Years ago, a systems administrator may have configured a Certification Authority Authorization (CAA) DNS record to lock certificate issuance to a single enterprise provider. Because manual renewals happened once every year or two, everyone forgot that record existed. Now that the CA/Browser Forum roadmap is steadily shrinking certificate validity windows toward 47 days, manual ordering is becoming unsustainable, and automated issuance hits that legacy security policy head-on.

What CAA Records Do and Why ACME Hits Them

Certification Authority Authorization, standardized in RFC 6844 and updated in RFC 8659, is a DNS record type designed to prevent unauthorized certificate authorities from issuing certificates for your domain. Before any publicly trusted certificate authority (CA) can sign a certificate, industry baseline requirements mandate that the CA must query the domain's authoritative DNS servers for CAA records. If your domain has no CAA records at all, any trusted CA is allowed to issue a certificate, provided you pass domain control validation. However, as soon as even a single CAA record exists on your domain, the rules change completely. The presence of a CAA record acts as an explicit whitelist. If a CA checks your DNS and does not see its own designated identifier listed in an issue or issuewild property tag, it must immediately refuse to issue the certificate, even if you successfully answered an ACME HTTP-01 challenge five seconds earlier. When a site used manual certificates from an enterprise vendor, the security team often added a CAA record naming only that specific vendor. When you install an ACME client configured to talk to Let's Encrypt, Sectigo, Actalis, or another automated provider, the CA executes its mandatory pre-issuance check, finds the legacy CAA record, and rejects the order. If you run into validation quirks while routing traffic through an edge layer, you may also want to review our guide on choosing between DNS-01 and HTTP-01 behind external proxies.

Step 1: Query Your Domain for Active CAA Records

The first step in diagnosing this failure is reading exactly what the public certificate authorities see when they query your authoritative nameservers. Do not rely on what is displayed in your hosting control panel, because internal DNS management interfaces sometimes hide raw record types or cache older zone files. Use the dig utility to query your domain directly for CAA records. Make sure to query an external public resolver or your domain's authoritative nameservers directly.

BASH

dig CAA example.com +noall +answer

If CAA records are active on the apex domain, you will see output structured like this illustrative example:

TEXT

example.com.    3600    IN    CAA    0 issue "sectigo.com"
example.com.    3600    IN    CAA    0 iodef "mailto:[email protected]"

In this output, each CAA record contains three components:

Flag: Usually set to 0. If set to 128 (the critical flag), a CA must abort issuance if it encounters a tag it does not understand.
Tag: Specifies the rule type. The issue tag explicitly names which CA can issue single-name or standard certificates. The issuewild tag governs wildcard certificates. The iodef tag specifies an email address or URL where CAs can report policy violations.
Value: The authorized domain identifier of the certificate authority.

In the example above, only Sectigo is allowed to issue certificates for example.com. If you run Certbot using Let's Encrypt's default directory, Let's Encrypt queries your domain, sees that only sectigo.com is whitelisted, and rejects the certificate request.

Step 2: Understand CAA Tree Climbing and Subdomains

A common point of confusion during ACME migrations occurs when you request a certificate for a subdomain, such as api.example.com or shop.example.com, but running dig CAA api.example.com returns an empty answer. According to RFC 8659, CAs must perform what the standard calls "tree climbing." When a CA checks authorization for api.example.com, it first queries api.example.com for CAA records. If no CAA record is found at the subdomain level, the CA strips the leftmost label and queries the parent domain, example.com. If example.com has a CAA record, that policy automatically applies to api.example.com. The tree climbing continues all the way up to the public suffix. This means a legacy CAA record placed at your apex domain five years ago silently restricts every single subdomain on your infrastructure, unless a specific subdomain defines its own overriding CAA record. There is an additional edge case with CNAME aliases. If api.example.com is a CNAME pointing to external-service.net, the CA will check api.example.com, follow the CNAME chain to external-service.net, and evaluate any CAA records present on the canonical target. If your automated certificate order is failing on a proxied or aliased subdomain, check the target of the CNAME as well.

Step 3: Add the Authorized Issuer Tag for Your ACME Client

You do not need to delete your existing CAA records to fix ACME issuance. CAA records are designed to be additive. You can authorize multiple certificate authorities simultaneously by creating multiple issue records. If your organization still purchases manual certificates from a commercial provider for specific systems, but you want to use automated ACME issuance for web servers, you simply add an additional issue record containing the domain identifier of your ACME provider. Common CA identifiers include:

Let's Encrypt: letsencrypt.org
Actalis: actalis.it (or actalis.com depending on the issued endpoint specification)
Sectigo: sectigo.com
DigiCert: digicert.com
Google Trust Services: pki.goog

To allow both a legacy provider and Let's Encrypt to issue certificates for your domain, configure your zone file or DNS management interface with multiple records. In standard BIND zone format, the records look like this:

TEXT

example.com.    3600    IN    CAA    0 issue "sectigo.com"
example.com.    3600    IN    CAA    0 issue "letsencrypt.org"
example.com.    3600    IN    CAA    0 issuewild "letsencrypt.org"

Notice the issuewild record. If you plan to issue wildcard certificates (for example, *.example.com), be aware that the presence of an issuewild tag overrides all standard issue tags for wildcard orders. If you have an issue record for Let's Encrypt but an issuewild record that only lists a commercial provider, Let's Encrypt will successfully issue single-domain certificates but will fail when attempting to order a wildcard.

Step 4: Verify DNSSEC and Propagation Before Re-running ACME

Once you have added the required CAA record to your authoritative DNS zone, avoid running the ACME client immediately in a tight loop. Repeated failures can cause your ACME client to hit provider rate limits, locking your account out for several hours. First, query your authoritative nameservers directly using dig to confirm that the new records are being served. Second, verify that your DNSSEC chain is healthy if DNSSEC is enabled for your zone. When a certificate authority performs a CAA lookup, it performs a strict DNSSEC validation check. If your zone has an invalid RRSIG record, an expired key, or a broken delegation signer (DS) record at the registrar, your DNS provider might return the CAA record to standard resolvers, but the CA's validating recursor will receive a SERVFAIL error. Under RFC rules, if a CAA query results in a DNSSEC SERVFAIL or a network timeout, the CA cannot assume no records exist. It must treat the lookup as a hard failure and refuse issuance. If you suspect broader DNS transport issues, understanding why HTTPS alone does not protect from DNS spoofing provides useful context on how validating resolvers enforce transport authenticity. After confirming that dig CAA example.com returns the updated list of authorized issuers from public vantage points, trigger your ACME client manually. The client will complete domain control validation, the CA will confirm its identifier in your CAA response, and the signed certificate will be delivered to your server. Resolving CAA failures comes down to respecting the inheritance model. When automated issuance halts unexpectedly on a domain that previously ran manual certificates, do not disable your security controls or wipe the zone. Trace the DNS hierarchy from the hostname up to the apex, identify which historical policy is blocking the request, and append the specific issuer tag your ACME provider requires.