The issuewild tag is a CAA directive that authorizes a certificate authority to issue wildcard certificates for a domain. It can be used separately from ordinary certificate issuance, allowing tighter control over wildcard issuance. This matters because wildcard certificates often create broader trust exposure than single-name certificates.
What Issuewild Tag Means in CAA Policy
The issuewild tag is a CAA directive that tells certificate authorities whether they may issue wildcard certificates for a domain. It is separate from ordinary issuance rules, so domain owners can permit wildcard issuance without broadly relaxing certificate controls.
How Issuewild Changes Certificate Authority Authorization
CAA records are an authorization signal for certificate issuance, not a cryptographic control over the certificates themselves. The issuewild tag applies specifically to wildcard requests, which means a CA can be allowed to issue only if the requested certificate matches the policy expressed in DNS.
That distinction matters because wildcard certificates can cover many hostnames under a single label, so the policy decision is about scope. A domain may permit standard certificates while still restricting wildcard issuance, or it may allow one CA to issue wildcards while denying others.
Why Issuewild Exists in Certificate Governance
Issuewild is useful when organizations want finer control over delegation. It lets a domain owner express a narrower trust boundary for wildcard coverage, which is especially relevant when different teams, services, or environments rely on certificates with different blast radii.
Operationally, the tag helps separate the question “may this CA issue any certificate for this domain?” from “may this CA issue a wildcard certificate for this domain?” That separation supports policy precision, reduces ambiguity, and avoids granting broader issuance rights than necessary.
How Issuewild Works with Other CAA Directives
Issuewild is commonly evaluated alongside other CAA tags such as issue and iodef. Together, they define who may issue, what type of issuance is allowed, and how policy reporting or escalation should be handled when issuance checks fail or are disputed.
In practice, issuewild does not replace certificate lifecycle management, DNS control, or CA vetting. It is a policy layer that depends on correct DNS publishing and on certificate authorities honoring CAA checks before issuance.
Risk and Threat Considerations
Wildcard certificates expand trust across multiple hostnames, so an overly permissive or misconfigured issuewild policy can widen the impact of a certificate compromise or unauthorized issuance. The main security question is whether wildcard delegation matches the actual operational need.
Failure mechanism: If wildcard issuance is allowed too broadly, a single certificate can validate many services, increasing the value of theft, mis-issuance, or misuse. If DNS CAA records are absent, stale, or incorrect, the domain owner may lose the intended issuance boundary.
Impact: An attacker or mistaken request can gain a certificate that covers more subdomains than intended, which can increase impersonation risk, complicate containment, and make certificate governance harder to audit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | CAA governs issuance authorization for TLS certificates tied to trust material. |
| AC-3 — Access Enforcement | issuewild is an authorization rule that constrains who may issue wildcard certificates. | |
| Recommendation — Align certificate issuance policy with SC-12 to control trust-material authorization and lifecycle decisions. Apply AC-3-style enforcement to restrict wildcard issuance to approved certificate authorities. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | CAA policy is an access-style control over certificate issuance permissions. |
| Recommendation — Document and enforce certificate issuance permissions under A.5.15 to limit wildcard authorization. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate issuance policy is part of controlling and reviewing authorized service access paths. |
| Recommendation — Use CIS-5 governance to review which authorities may issue wildcard certificates. | ||
| NIST CSF 2.0 | PR.AA-05 — Asset Management and Identity Access Protection | CAA expresses a trust boundary for issuance authorization and controlled access to certificate trust. |
| Recommendation — Use PR.AA-05 to limit certificate issuance to authorized issuers and required certificate scopes. | ||
Practitioner Guidance
Why practitioners should care: Use issuewild only when wildcard certificates are operationally necessary, and align it with the smallest issuer set that can meet the requirement. This keeps certificate policy tied to real deployment needs rather than convenience.
What to watch for: Review DNS CAA records as part of certificate governance so wildcard authorization stays intentional, current, and consistent across environments. The key judgement is whether wildcard issuance deserves a broader approval path than single-name issuance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
