Combine issuers and handle wildcards
05Authorizations within one relevant set are additive. A wildcard-specific policy can replace the ordinary issue policy for wildcard names.
For one request by ca1.example.net containing example.com and *.example.com, issue authorizes ca1 but issuewild authorizes only ca2. The ordinary name passes and the wildcard fails; ca1 cannot issue this combined request under this policy.
Key idea: Every requested name must pass its applicable CAA check.
Terms
- CAA
- Certification Authority Authorization: DNS policy checked by a CA before it issues a certificate.
- CA
- Certification Authority: an issuer of certificates under a stated certificate policy.
- Relevant RRset
- The first nonempty CAA resource-record set found by the RFC’s lookup algorithm. A set can contain several properties.
- Property tag
- The case-insensitive name of a CAA property, such as issue, issuewild or iodef.
- Wildcard name
- A certificate name beginning with *., such as *.example.com. For CAA lookup, remove that leading *. first.
- CP / CPS
- Certificate Policy / Certification Practices Statement. Section 3 allows an exception specified in the relevant CP or CPS; the worked examples assume none applies.
Rules & examples
Every requested name must pass its applicable CAA check.
- Multiple issue records authorize alternatives. issue with an empty issuer-domain-name, such as ";", requests no issuance. An issue value that fails the §4.2 ABNF MUST be treated like an empty issuer-domain-name; it is not an authorization grant.
- CAA authorizations are additive: an empty-issuer record plus a valid grant to ca1.example.net has the same result as the valid grant alone. The empty record is not a veto over all other records (§4.2).
- For a non-wildcard request, each issuewild property MUST be ignored. For a wildcard request with at least one issuewild in the relevant set, each issue property MUST be ignored; without issuewild, issue applies to the wildcard too (§4.3).
- Parameters can further constrain issuance by a particular issuer; their semantics are determined by that issuer. They are separated by semicolons, and parameter names can contain internal hyphens. These parameter-free examples do not implement issuer account binding or ACME extensions (§4.2; verified5934).
- For a certificate containing both example.com and *.example.com, the CA MUST verify both names. Passing the ordinary-name policy does not excuse failing the wildcard policy (§3).
Fictional names, inert records and simulated DNS answers. The examples assume no CP/CPS exception and no extra issuer-defined parameter constraint. Passing CAA does not satisfy the other checks needed to issue a certificate.
Sources
New to this? Start hereA quick picture + helpful background
Check the domain’s issuer list before signing
Imagine a certificate printer checking a domain’s published list of permitted signing organizations. That list is only one check before printing; it is not the later reader’s test of an existing certificate. This is an analogy for issuance policy, not a complete certificate system.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.