Confirm that CAA is the reason for refusal
A CAA refusal needs the requested certificate name, applicable CAA policy and actual issuing authority; change only the policy that blocks the approved issuer.
CAA restricts which public certificate authorities may issue for a DNS name. A certificate can fail after website resolution and challenge validation if the applicable CAA set excludes its actual issuer. Use the recorded refusal, requested subdomain or wildcard and chosen issuer to trace the policy; general certificate setup is a separate task.
Capture the exact error, requested hostnames, whether a wildcard such as *.example.com is involved, and the intended certificate issuer. A vague “validation failed” message is not proof of a CAA fault: DNS, HTTP challenges, TLS routing and rate limits also cause failures. Panel configuration may choose an authority without exposing it in the customer view; ask the hosting provider which issuer the attempted order used.
Understand where the policy can come from
CAA is checked for the requested name and, if no relevant CAA record is found there, at successive parent names. A request for shop.example.com can therefore be limited by a CAA record at example.com. A CNAME path can also matter under the CAA processing rules. A record at the website’s A-address host is not automatically the same as a policy for the requested certificate name, so trace the DNS name deliberately.
The issue tag concerns ordinary certificates; issuewild gives a separate policy for wildcard certificates when present. An iodef record is a reporting contact, not issuer authorisation. Multiple CAA records may authorise different issuers. Never treat the presence of one permitted issuer as permission for every authority, or a wildcard permission as a reason to change the whole zone.
Trace the CAA policy for the requested name
- Find the domain’s delegated nameservers and ask one actual authoritative server for the requested name:
dig @ns1.provider.example shop.example.com CAA +noall +answer. Replace the illustrative nameserver and hostname. - Query parent names in turn, for example
dig example.com CAA +short. For a hostname that is a CNAME, record its target and ask the DNS provider or certificate service to trace the CAA processing path too. - Compare the returned
issueorissuewildvalues with the issuer actually used by the request. The CA’s required identifier comes from that CA or service, not from a guessed brand name. - Query through a normal recursive resolver and compare with authoritative answers. A recently changed CAA policy may still be cached for its previous TTL.
Check the exact owner name shown by the DNS panel. A relative-name field may append example.com automatically. Some DNS providers publish service-managed CAA records that are visible in public answers but absent from the editable list; ask that provider how those records are managed.
If shop.example.com has no CAA answer, also inspect example.com; a parent policy can explain why issuance for the child is refused.
Change only the policy that conflicts
Have the domain owner and certificate service confirm which CA should remain authorised, including current and planned renewals. If the issuer is legitimate and the applicable policy omits it, add its exact CAA authorisation at the authoritative DNS provider while preserving other required issuers. For an ordinary certificate, check issue; for a wildcard request, check whether issuewild controls it. If the issuer is unexpected, do not simply authorise it: ask the host why that issuer was selected or whether a different approved authority can be used.
Removing all CAA records may allow issuance by any otherwise eligible public CA and changes the domain’s intended security policy. Treat it as a deliberate policy decision, not a routine repair shortcut. Do not copy Cloudflare-specific automatic CAA values into a non-Cloudflare setup or claim that a particular CA is always used by Novasean. If the domain has delegated subzones or a CDN/proxy, coordinate with those operators so the certificate at each layer has an applicable policy.
Verify the revised answer and issuance
After saving, query the exact CAA owner and the effective policy path again at authoritative servers. Wait for cached previous answers to expire, then retry the certificate request once using the host’s normal workflow. Record the new order result and inspect the issued certificate for the requested names, issuer and validity dates. Successful CAA checks alone do not prove the HTTP or DNS challenge will pass.
If the change does not help, capture full DNS replies including status, the CA’s CAA error and timestamp. SERVFAIL can prevent an authority from reliably checking policy; diagnose DNSSEC or nameserver health before adding more CAA records. If the policy change caused an unintended effect, restore the recorded prior CAA set after assessing active renewals. An already issued certificate is not made invalid merely by a later CAA edit, but its next issuance or renewal may be blocked.
Common questions
Do I need CAA records to obtain a certificate? No. Absence of a CAA policy does not itself block issuance; other validation requirements still apply.
Why does a subdomain fail when it has no CAA record? It may inherit a restrictive parent policy, or a CNAME path may lead to an applicable policy elsewhere.
Can I add a CAA record in DirectAdmin? Only if its DNS zone is authoritative and the account offers that record type. Otherwise edit the live external DNS zone.
Does a CAA change guarantee issuance? No. The CA still needs successful domain validation and must apply its own checks.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.