Which Name the CA Validates - Authorization Domain Names, CNAME Following, and Label Pruning from 2026-11-15

First Published: 2026-10-29
Last Updated: 2026-10-29

Certification Authorities (CAs) that issue publicly trusted TLS certificates refer to the names they validate to confirm applicant control as Authorization Domain Names (ADNs). The ADN may be the same as the name applied for, or it may be different. The CA/Browser Forum's TLS Baseline Requirements (hereafter referred to as BR) establish a single process for determining this ADN, effective November 15, 2026. CAs first select a validation method, and then, in the scope permitted by that method, they follow the CNAME of the applied-for name, prune the leftmost label, and use the remaining name as the ADN. Both CNAME following and label pruning are optional (MAY) steps, permitted only when specified in the method table, and CNAME following must precede label pruning.

This article examines this process and the tables in the BR, comparing them to the older definitions in version 2.2.7. It then analyzes how AWS Certificate Manager (hereafter referred to as ACM), Amazon Trust Services (hereafter referred to as ATS), and Let's Encrypt document these procedures, noting what they cover and what they omit. In addition to the ADN's CNAME, certificate issuance involves CNAMEs for challenge delegation, in CAA lookups, and when a CA resolves the name in an HTTP method. This article addresses these four types separately.

This article does not cover pricing, comparisons between CAs, the number of perspectives for Multi-Perspective Issuance Corroboration, CAA design, or the schedule for ending ACM email validation. The information presented was verified as of October 28, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Old Definition and the New Procedure
4. The Method Table
5. Four Kinds of CNAME in Certificate Issuance
6. What the ACM Documentation Says and Does Not Say
7. The Amazon Trust Services and Let's Encrypt Documents
8. What This Configuration Returned
9. Failure Modes
10. Frequently Asked Questions About Authorization Domain Names
11. Summary
12. References

1. Scope and Assumptions

This section will first define the intended audience of this article, what changes on November 15, 2026, the scope of the content, the source materials consulted, and how to distinguish between different entities that may share the same name. To state the conclusion upfront, there are seven key points.

BR version 2.3.1, Section 3.2.2.4, describes a five-step process for determining the ADN. The CA begins with the applied-for name, selects a validation method, and if the name is a Fully Qualified Domain Name (FQDN), performs the CNAME and Prune steps in that order, then sets the remaining name as the ADN. For wildcard names, the *. prefix is removed, and only the Prune step is performed.
The CNAME and Prune steps are only permitted (MAY) if the chosen method has a check (✔) in the CNAME and Prune columns, respectively. The CA may choose to set the ADN to the applied-for FQDN itself (or the name with the *. prefix removed for wildcard names) without following any CNAME chains or performing any Prune operations.
The HTTP methods (3.2.2.4.18 and 3.2.2.4.19) and the ALPN method (3.2.2.4.20) do not allow for Wildcard, Prune, or CNAME operations. With these methods, the ADN is simply the applied-for name, and wildcard names cannot be selected.
Prior to November 15, 2026, the CA may follow Section 3.2.2.4 of BR version 2.2.7. That version defined ADN by stating that the FQDN returned from a DNS CNAME lookup could be used and that labels could be pruned, without specifying a particular order. The SC-101v2 ballot page states that, under one reading of this definition, an operator that a name points to with a CNAME might be able to get certificates for any subdomain of that name.
Four types of CNAME records are relevant to certificate issuance. The ADN CNAME is the CNAME record for the applied-for name itself. The challenge delegation CNAME is a CNAME record with an underscore-prefixed label, such as _acme-challenge or ACM's _x1, and does not alter the ADN. CAA lookups and the resolution of the name when the CA uses an HTTP method also involve separate CNAME chain resolutions.
ACM documentation describes that wildcards and their original names return the same CNAME, specifies a limit on CNAME chains, states that wildcards cannot be used with HTTP validation, allows a superdomain as the validation domain with email validation, and outlines three ACME scopes. The term ADN and the section numbers related to BR methods were not found in the ACM documentation.
The ATS CP/CPS version 2.7 (August 19, 2026) glossary defines ADN and Base Domain Name using the older definitions from BR version 2.2.7. The same document includes 3.2.2.4.8 in its list of supported methods. BR, in both its older and current versions, states that CAs MUST NOT rely on 3.2.2.4.8 from March 15, 2026. This article does not state that either is incorrect, but simply lists the information.

1.1 Intended Audience

The intended audience for this article includes platform and security professionals who operate ACM DNS validation, CNAME delegation for ACME dns-01, and CNAMEs to CDNs and SaaS platforms. Specifically, it is written for readers who hold one of the following four assumptions:

The service provider to which the CNAME is pointed can obtain certificates for your names.
Validating the apex domain allows obtaining certificates for all subdomains.
Even with HTTP validation, wildcard certificates can be obtained.
ACM's validation process follows the method described in BR Section 3.2.2.4.7.

None of these assumptions are always correct. Whether they are valid depends on the method and the CA's choice. In other cases, the documentation does not state it. Sections 3 through 7 will examine each of these assumptions, citing specific passages from the relevant documentation.

1.2 What Changes on November 15, 2026

BR, Section 1.2.2, includes the following text in the row for November 15, 2026:

Authorization Domain Names must be derived based on the validation method to be used.

The beginning of Section 3.2.2.4 states the transition period as follows:

Prior to 2026-11-15, the CA SHALL adhere to Section 3.2.2.4 (and its subsections) of these Requirements
*or* Section 3.2.2.4 of Version 2.2.7 of the Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates. Effective 2026-11-15, the CA SHALL adhere to Section 3.2.2.4 of
these Requirements.

What changes on November 15, 2026, is the text that a CA may follow. From that date forward, Section 3.2.2.4 of BR version 2.2.7 will no longer be applicable, and only the current procedure and method table will remain. This change was incorporated in ballot SC-101v2 and was included in BR version 2.2.9 (effective August 6, 2026).

1.3 Scope and Exclusions

This article covers the definition of ADNs, the process for determining ADNs, the method table, the transition period, retired methods, the ADN for the reverse lookup method, the distinctions between four types of CNAME records, and the documentation for ACM, ATS, and Let's Encrypt.

This article does not cover the following topics, as they are addressed in other articles on this site or in other articles in the same series:

The number of perspectives and the methods covered in Section 3.2.2.9 (Multi-Perspective Issuance Corroboration), which is covered in "When Five Network Perspectives Must Agree."
The design of CAA's issue, issuewild, accounturi, and validationmethods parameters, which is covered in "What CAA Can and Cannot Stop When DNS Control Is the Weak Link."
The timeline for ending email validation for ACM, and the process for switching validation methods, which is covered in "Moving AWS Certificate Manager Off Email Validation."
ACM's three issuance paths and ACME configuration, which is covered in "How AWS Certificate Manager Issues Public Certificates."
The revisions to BR and the timeline of industry deadlines, which is covered in "TLS Certificate Ecosystem History and Timeline."
Root programs' decisions to remove trust in a CA, and certificate revocation and trust stores, which are covered in two other articles in the same series.

This article does not discuss pricing or compare CAs. It briefly mentions IP address certificate methods in one sentence regarding the ADN for the reverse lookup method. It also briefly mentions Onion domains in relation to the columns in the method table.

1.4 The Check Date and the Sources Read

The information was verified on October 28, 2026. The materials reviewed are as follows:

Current version of BR, 2.3.1 (dated 4-Oct-2026). Obtained from the main branch of the cabforum/servercert GitHub repository, the file docs/BR.md.
Version 2.2.7 of BR (tag BRs/v2.2.7) and version 2.2.9 of BR (the file docs/BR.md at commit ad77bf1975fe1dffebb9cbdb7280eb80b94f5c45, which merged PR #627 for SC-101v2). The version 2.2.9 was confirmed by checking the Version value at the beginning of the file.
The ballot page for SC-101v2 on cabforum.org.
Pages from the ACM User Guide covering DNS validation, Email validation, HTTP validation, Validate domain ownership, public certificate characteristics and limitations, ACME domain validation, and ACM concepts. Also, the ACM API Reference page for DomainValidation, and the ACM FAQ.
Two articles from the AWS re:Post Knowledge Center, and two articles from the AWS Security Blog.
Version 2.7 of ATS's CP/CPS (dated August 19, 2026).
The Challenge Types page on Let's Encrypt.

As of the verification date, no ballots that change the ADN procedure were found on the cabforum.org Server Certificate Working Group ballot list, following the SC-101v2 ballot.

The record in Section 8 is of the requests sent to ACM on October 28, 2026, specifically for this article.

1.5 Words with the Same Spelling, Different Meanings

This article discusses terms that share the same spelling but refer to different concepts.

validation: While the term "validation" is used, it refers to different methods depending on the context. Specifically, it applies to the various methods listed in BR Section 3.2.2.4 (e.g., 3.2.2.4.7), ACM's ValidationMethod (including DNS, EMAIL, and HTTP), ACME's challenges (e.g., dns-01, http-01), and the values within CAA's validationmethods. Although the same word is used, these represent distinct concepts. Section 5 of "What CAA Can and Cannot Stop When DNS Control Is the Weak Link" presents these distinctions in a table. This article always refers to a BR method by its number.
CNAME: This article differentiates between the use of "CNAME" in the context of ADN, challenge delegation, CAA lookups, and when a CA resolves the name in an HTTP method (as detailed in Section 5).
prune: Within this article, "prune" is used to refer to the name of a step in BR's procedures, specifically indicating the removal of a single leftmost label.
Base Domain Name and apex: In BR, a "Base Domain Name" refers to the portion immediately to the left of a public suffix or a suffix managed by the registry, encompassing both the node and the suffix. BR also lets a gTLD with ICANN Specification 13 in its registry agreement be used as the Base Domain Name. In ACM's documentation, the term "apex domain" is defined in the ACM concepts page. While both provide examples such as example.com and example.co.uk, they represent different definitions within separate documents. This article uses "Base Domain Name" when describing BR's procedures and "apex" when referencing ACM's documentation.

2. How to Read the Tables

This section defines the columns in the tables from Sections 3 through 7, as well as how this article writes the state of the sources. The other two articles in the same series use the same conventions.

2.1 Last Two Columns

The tables in this article end with the following two columns.

Column	What the cell holds
`Where It Is Written`	The document, the section, and the check date of the statement in the row
`No Statement Found`	What the sources in Section 1.4 do not state about the row, with the scope searched; `—` when nothing is missing

Rows with a non-empty No Statement Found column indicate that, despite searching the sources in Section 1.4, no relevant statement was found for that particular matter. This does not indicate that the matter is nonexistent or does not occur.

2.2 Normative Words

BR's normative terms (MUST, MUST NOT, SHALL, SHOULD NOT, MAY) are written in English capital letters. This article does not rephrase these terms in the body of the text. In the method table, a check (✔) indicates that the step is permitted as a MAY. It does not indicate that the CA performs that step.

BR specifies dates for each method in two ways. The phrase "SHOULD NOT be used to issue Subscriber Certificates" indicates a state where the method is not recommended for use. Conversely, "The CA MUST NOT rely on this method" indicates a state where the CA may no longer rely on that method. This article treats these two conditions separately.

2.3 No Statement Found, Not Listed, the Sources Disagree, and Inference

This section describes four distinct situations, using different terminology.

Missing Information: Despite searching the sources in Section 1.4, no text was found that addressed the specific matter. In the main text, this will be written as "no statement was found," accompanied by a description of the search scope.
Information Not Listed: The item is not included in the list or table. In the main text, this will be written as "the documentation does not list."
Conflicting Information: The sources disagree; two statements describe the same matter but are irreconcilable. In the main text, this will be written as "the sources disagree," and both statements, along with their sources, will be presented. This article does not decide that either statement is wrong.
Inference: This refers to something derived from the text in the materials. In the main text, the same sentence states that it is this article's reading and not a statement in any source.

3. The Old Definition and the New Procedure

This section lists the definitions of ADN in BR version 2.2.7, as well as the current five-step process, and quotes the reasons for the change that the SC-101v2 ballot page gives.

3.1 Definition of ADN for BR Version 2.2.7

Section 1.6.1 of BR version 2.2.7 defined ADN as follows:

Authorization Domain Name: The FQDN used to obtain authorization for a given FQDN to be included in a
Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain
validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "*." from
the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or
more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one
of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain
validation.

This definition stated, in separate sentences, that CNAMEs may be followed and that labels may be pruned. It did not specify the order in which these actions should be performed, how many times a CNAME may be followed, or which methods are allowed.

Permissions specific to each method were described in the notes in the body of each method. For example, the note for 3.2.2.4.7 stated:

Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs
that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard
Domain Names.

The notes for methods 3.2.2.4.18 and 3.2.2.4.19, related to the HTTP method, stated the opposite. The note for method 3.2.2.4.20, related to the ALPN method, contained essentially the same content, with the phrase "Once the FQDN has been validated using this method," added at the beginning.

Note: The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN
unless the CA performs separate validations for each of those other FQDNs using authorized methods. This
method is NOT suitable for validating Wildcard Domain Names.

The text for 3.2.2.4.22 described an exception regarding CNAME resolution that overrides the ADN definition.

For this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes
of domain validation. This prohibition overrides the Authorization Domain Name definition. CNAME records MAY
be followed when resolving the Persistent DCV TXT Record.

3.2 Current 5-Step Procedure

Version 2.3.1 of BR, Section 1.6.1, defines ADN in a descriptive sentence without including any steps.

Authorization Domain Name: The FQDN used to perform validation of domain authorization or control for a
given FQDN or Wildcard Domain Name.

The steps themselves have been moved to Section 3.2.2.4. The full text is as follows:

The CA MUST follow this process when choosing the Authorization Domain Name (ADN) for validation of each
applied-for FQDN or Wildcard Domain Name:

1. Initialize A to the applied-for FQDN or Wildcard Domain Name.
2. Choose a validation method. If A is a Wildcard Domain Name, the CA MUST choose a validation method with a
   check in the Wildcard column below. If A is an Onion Domain Name, the CA MUST choose a validation method
   with a check in the Onion column below.
3. If A is an FQDN:
    1. If the validation method has a check in the CNAME column below, the CA MAY replace A with the result
       of a DNS CNAME lookup of A. This step may be repeated.
    2. If the validation method has a check in the Prune column below and A is not equal to the Base Domain
       Name of A, the CA MAY replace A with the result of pruning the leftmost Domain Label from A. This step
       may be repeated.
4. If A is a Wildcard Domain Name:
    1. Remove "*." from the left-most portion of A.
    2. If the validation method has a check in the Prune column below and A is not equal to the Base Domain
       Name of A, the CA MAY replace A with the result of pruning the leftmost Domain Label from A. This step
       may be repeated.
5. Use A as the ADN.

The following five points can be derived from this procedure:

The procedure itself is a MUST. The CA has to choose the ADN by this procedure.
The method must be selected before the ADN. Choosing a method with a ✔ in the Wildcard column for wildcard names, and a method with a ✔ in the Onion column for Onion domains, is a MUST.
For an FQDN, the CNAME step (3.1) precedes the Prune step (3.2). Both steps are permitted as MAY and can be repeated, but only for methods with a ✔ in the corresponding column of the table.
The Prune step stops when A equals its Base Domain Name.
In step 4 for wildcard names, only the step that removes *. and the Prune step are present; the CNAME step is not included. That the CNAME step is not permitted for wildcard names is this article's reading of how the procedure is written; BR does not state this in a single sentence.

How the CA Chooses the ADN from 2026-11-15

The table following the procedure will be reviewed in Section 4. The sentence below the table states that Onion domains are validated according to Appendix B, and that a completed validation can be used for multiple certificate issuances over time.

3.3 Background of the SC-101v2 Ballot

The background section of the SC-101v2 ballot states that the previous definition had two issues. The first was that the definition's wording, while outlining procedures, took the form of a brief explanation, making it unclear whether each step could be performed independently, sequentially, or repeatedly. The second issue was that, depending on interpretation, the definition potentially allowed certificates to be issued for names over which the applicant had not demonstrated control.

Regarding the second issue, the ballot explains this with the following example:

Specifically, one interpretation of the current definition of an ADN is that a CA may prune labels from the
left-hand side of the FQDN, then follow one or more CNAMEs, and then use the resulting FQDN as the ADN.
However, just because example.com has a CNAME pointing to example.org, that does not give the operators of
example.org any control over subdomains of such as blog.example.com. Under this interpretation, an entity
capable of demonstrating control of a CNAME (such as a CDN operator) might be able to get issuance of
certificates for arbitrary subdomains of names that are CNAMEd to them. This is not good.

Subsequently, the ballot outlines four key changes. The fourth of these is:

Following CNAMEs must happen before pruning labels, if both operations are performed.

The ballot page also states that every method in fact validates control of the ADN, not of the applied-for FQDN, and that this has always been true.

This means that validation data reuse also works at the ADN level: if two applied-for FQDNs can both be
turned into the same ADN, then demonstrating control of that ADN is valid for the issuance of both applied-for
FQDNs.

The ballot page also states that this is not expected to be a disruptive change for most CAs, as it aligns with the most common interpretation of the ADN definition.

The voting results show 27 approvals and 0 rejections from the certificate issuer side, while the certificate consumer side showed 4 approvals (Apple, Google, Microsoft, Mozilla) and 0 rejections. The 27 approvals included Amazon and Let's Encrypt. The proposer is Aaron Gable from Let's Encrypt / ISRG. The voting period was from June 23 to June 30, 2026, and the intellectual property review period was from July 7 to August 6, 2026. The ballot page states that the only substantive difference between SC-101v2 and SC-101 is the addition of an effective date to the change in Section 3.2.2.5.3.

3.4 Transition Period Until November 15, 2026

The Summary of the Ballot on the ballot page states that due to the extensive nature of the changes, CAs may continue to adhere to the previous version's Section 3.2.2.4 until November 15, 2026. This provision is the sentence at the beginning of Section 3.2.2.4 quoted in Section 1.2.

Therefore, as of October 28, 2026, a CA may comply with either version 2.3.1 of BR's Section 3.2.2.4 or version 2.2.7 of BR's Section 3.2.2.4. During this period, a CA's CP/CPS that carries the old definitions is consistent with the BR text (this article's reading: the sentence names only Section 3.2.2.4, and the old definitions are in Section 1.6.1 of version 2.2.7). The glossary in ATS's CP/CPS, as described in Section 7.1, is an example of this.

3.5 Related Provisions Introduced Around the Same Time

Some of the provisions related to ADN were introduced prior to the SC-101v2 ballot. This article checked the text of each version to see which version introduced each provision.

Provision	First BR version with the text	Effective date in the text	Where It Is Written	No Statement Found
Records of verification activities MUST include `the ADN used (if applicable and different from the applied-for FQDN)`	2.2.7 (SC099)	2026-07-15	BR 2.3.1 Section 5.4.1; BR 2.2.7 Section 5.4.1 (checked 2026-10-28)	—
The clause `including CNAME lookups performed while choosing the ADN`, added to the requirement for DNSSEC validation on all DNS queries by the Primary Network Perspective (that requirement is already in BR 2.2.7, effective 2026-03-15)	2.2.9 (SC-101v2)	—	BR 2.3.1 Section 3.2.2.4; BR 2.2.9 Section 3.2.2.4; BR 2.2.7 Sections 1.2.2 and 3.2.2.4 (checked 2026-10-28)	—
For reverse address lookup, `the ADN for this method MUST be exactly the FQDN returned from the reverse-IP lookup`	2.2.9 (SC-101v2)	2026-11-15	BR 2.3.1 Section 3.2.2.5.3 (checked 2026-10-28)	—

The requirements for DNSSEC validation, as well as the partial exception for the three email methods, are addressed in the DNSSEC paragraph of "TLS Certificate Ecosystem History and Timeline." This article only specifies that CNAME lookups performed while selecting an ADN are also subject to DNSSEC validation.

3.6 The Old Text and the Current Text Side by Side

Item	BR 2.2.7	BR 2.3.1	Where It Is Written	No Statement Found
Definition of ADN	Contains the procedure: CNAME lookup, removal of `*.`, and pruning, in separate sentences	Descriptive only: `The FQDN used to perform validation of domain authorization or control`	Section 1.6.1 of each version	—
Order of CNAME and pruning	Not stated	CNAME step (3.1) is listed before the Prune step (3.2)	Section 1.6.1 (2.2.7); Section 3.2.2.4 (2.3.1)	—
Repetition	`zero or more Domain Labels` for pruning; not stated for CNAME	`This step may be repeated.` for both steps	Same	—
Which methods may prune or follow a CNAME	Per-method Notes on `other FQDNs that end with all the Domain Labels`; 3.2.2.4.22 overrides the CNAME part	One table in Section 3.2.2.4 with Wildcard, Prune, CNAME, and Onion columns	Section 3.2.2.4.x (2.2.7); Section 3.2.2.4 (2.3.1)	—
3.2.2.4.22 and CNAME	`MUST NOT use the FQDN returned from a DNS CNAME lookup`; `CNAME records MAY be followed when resolving the Persistent DCV TXT Record`	CNAME column is `-`; the method text has no sentence on CNAME	Section 3.2.2.4.22 of each version	Whether a CNAME may be followed while resolving the `_validation-persist` record: no statement was found in BR 2.3.1
Base Domain Name	`The portion of an applied-for FQDN`	`The portion of a given FQDN`	Section 1.6.1 of each version	—
Domain Contact	Defined in Section 1.6.1	Defined inside 3.2.2.4.12, the only method that uses it	Section 1.6.1 (2.2.7); Section 3.2.2.4.12 (2.3.1)	—

The change to the definition of the Base Domain Name can be read as making the stopping point of the Prune step depend on the current A, not on the applied-for name, because step 3.2 refers to "the Base Domain Name of A." This is this article's reading; the ballot page states only that the definition has been simplified.

4. The Method Table

This section copies the method table of Section 3.2.2.4, adds the dates for each method, and explains how to read a check (✔), the retired methods, and the ADN for the reverse address lookup method. Finally, it walks through the procedure with example names.

4.1 Four Columns by Method

The symbols in the table correspond to those used in the BR, where "✔" indicates that a selection or option is permitted in that column, and "-" indicates that it is not. The Dates in the BR column quotes Section 1.2.2 of the BR and the specific text within each method's description.

Method	Wildcard	Prune	CNAME	Onion	Dates in the BR	Where It Is Written	No Statement Found
3.2.2.4.4 Constructed Email to Domain Contact	✔	✔	✔	-	`SHOULD NOT` from 2026-03-15; `MUST NOT rely` from 2028-03-15	BR 2.3.1 Sections 3.2.2.4, 3.2.2.4.4, and 1.2.2 (checked 2026-10-28)	—
3.2.2.4.7 DNS Change	✔	✔	✔	-	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.7	—
3.2.2.4.12 Validating Applicant as a Domain Contact	✔	✔	-	-	— (only when the ADN's Base Domain Name equals the ADN, and the CA is the Domain Name Registrar of the ADN or an Affiliate of the Registrar)	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.12	—
3.2.2.4.13 Email to DNS CAA Contact	✔	✔	✔	-	`SHOULD NOT` from 2026-03-15; `MUST NOT rely` from 2028-03-15	BR 2.3.1 Sections 3.2.2.4, 3.2.2.4.13, and 1.2.2	—
3.2.2.4.14 Email to DNS TXT Contact	✔	✔	✔	-	`SHOULD NOT` from 2026-03-15; `MUST NOT rely` from 2028-03-15	BR 2.3.1 Sections 3.2.2.4, 3.2.2.4.14, and 1.2.2	—
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact	✔	✔	✔	-	`SHOULD NOT` from 2026-03-15; `MUST NOT rely` from 2027-03-15	BR 2.3.1 Sections 3.2.2.4, 3.2.2.4.16, and 1.2.2	—
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact	✔	✔	✔	-	`SHOULD NOT` from 2026-03-15; `MUST NOT rely` from 2027-03-15	BR 2.3.1 Sections 3.2.2.4, 3.2.2.4.17, and 1.2.2	—
3.2.2.4.18 Agreed-Upon Change to Website v2	-	-	-	✔	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.18	—
3.2.2.4.19 Agreed-Upon Change to Website - ACME	-	-	-	✔	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.19	—
3.2.2.4.20 TLS Using ALPN	-	-	-	✔	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.20	—
3.2.2.4.21 DNS Labeled with Account ID - ACME	✔	✔	-	-	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.21	—
3.2.2.4.22 DNS TXT Record with Persistent Value	✔	✔	-	-	—	BR 2.3.1 Sections 3.2.2.4 and 3.2.2.4.22	—
Appendix B.2.b	✔	✔	-	✔	—	BR 2.3.1 Section 3.2.2.4 and Appendix B	—

The combinations that can be read from the table are as follows:

When all three columns (Wildcard, Prune, and CNAME) are checked (✔), it indicates the email methods (3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14), the DNS method (3.2.2.4.7), and the phone methods (3.2.2.4.16, 3.2.2.4.17). Of these, only the DNS method has no date in the BR text.
When Wildcard and Prune are checked (✔) but CNAME is marked with a dash (-), it corresponds to Sections 3.2.2.4.12, 3.2.2.4.21, 3.2.2.4.22, and Appendix B.2.b.
For the HTTP and ALPN methods, only the Onion column is checked (✔).
The rows in the table do not include any retired methods. The retired methods are listed in Section 4.3.

4.2 A Check Is a Permission, Not What the CA Does

The ✔ indicates that a step is permitted as a MAY option. It does not mean that the CA must perform that step, nor does it mean that the CA must not perform that step. For example, when validating www.example.com using the method described in 3.2.2.4.7, the CA may use www.example.com itself as the ADN, or it may use example.com as the ADN through the Prune step. The choice is up to the CA, and is not determined by the BR.

Conversely, steps marked with - in the column are not permitted within that method. When validating www.example.com using the HTTP method, the ADN is www.example.com itself. It is not possible to use the validation result for example.com, nor is it possible to select *.example.com.

This change, effective November 15, 2026, does not mean that the CA will no longer follow CNAME records or prune labels. What is changing is that the BR text itself now determines the methods that permit a step and the order in which those steps can be performed.

4.3 Retired Methods

Section 3.2.2.4 lists ten methods, each with a number but containing only a statement indicating that the method has been retired.

Method	Name in BR 2.3.1	Status in BR 2.3.1	Where It Is Written	No Statement Found
3.2.2.4.1	Validating the Applicant as a Domain Contact	`This method has been retired and MUST NOT be used.`	BR 2.3.1 Section 3.2.2.4.1	—
3.2.2.4.2	Email, Fax, SMS, or Postal Mail to Domain Contact	Same	Section 3.2.2.4.2	—
3.2.2.4.3	Phone Contact with Domain Contact	Same	Section 3.2.2.4.3	—
3.2.2.4.5	Domain Authorization Document	Same	Section 3.2.2.4.5	—
3.2.2.4.6	Agreed-Upon Change to Website	Same	Section 3.2.2.4.6	—
3.2.2.4.8	IP Address	Same; in BR 2.2.7 the method text remained, with `The CA MUST NOT rely on this method` effective March 15, 2026	BR 2.3.1 Section 3.2.2.4.8; BR 2.2.7 Sections 1.2.2 and 3.2.2.4.8	—
3.2.2.4.9	Test Certificate	Same	Section 3.2.2.4.9	—
3.2.2.4.10	TLS Using a Random Value	Same	Section 3.2.2.4.10	—
3.2.2.4.11	Any Other Method	Same	Section 3.2.2.4.11	—
3.2.2.4.15	Phone Contact with Domain Contact	Same	Section 3.2.2.4.15	—

3.2.2.4.8 underwent two changes. In version 2.2.7 of BR, the main text remained, accompanied by a statement that the CA MUST NOT rely on it from March 15, 2026. In version 2.2.9 of BR, the main text was replaced with the retirement statement. The prohibition against reliance takes effect from March 15, 2026, and is separate from the transition period ending on November 15. This distinction is relevant when referring to ATS CP/CPS in Section 7.1.

4.4 The ADN for the Reverse Address Lookup Method

In the IP address certificate methods, specifically 3.2.2.5.3 Reverse Address Lookup, the FQDN obtained using the reverse lookup method is used as the ADN and validated according to the method described in Section 3.2.2.4. Version 2.3.1 of BR states the following regarding this ADN:

Effective 2026-11-15, the ADN for this method MUST be exactly the FQDN returned from the reverse-IP lookup;
the ADN selection algorithm in section 3.2.2.4 does not apply.

From 2026-11-15, this method can use neither the CNAME step nor the Prune step. Furthermore, Section 1.2.2 states that CAs MUST NOT rely on this method from March 15, 2027. According to the ballot page, the substantive change from SC-101 to SC-101v2 was the 2026-11-15 effective date in the quoted sentence.

4.5 Following the Steps Using the Examples

The examples in this section use names found on the ballot page, such as example.com, example.org, and blog.example.com, as well as variations extending these names. In each example, whether the CA performs a permitted step is the CA's choice, and what is described here is the permitted range.

Example 1: www.blog.example.com is validated according to the process in 3.2.2.4.7, and none of the names have a CNAME record. The CNAME step changes nothing. In the Prune step, A may become either blog.example.com or example.com. The ADN may be www.blog.example.com, blog.example.com, or example.com.

Example 2: Consider an example from the ballot page. blog.example.com is validated, and example.com has a CNAME record pointing to example.org. One interpretation of the older definition suggested that blog.example.com could be pruned to example.com before following the CNAME to example.org, resulting in example.org being a valid ADN. However, in the current procedure, the CNAME step applies to the CNAME of blog.example.com while A is blog.example.com. After the Prune step moves A to example.com, there is no return to the CNAME step. The ADN may be either blog.example.com or example.com, but not example.org.

Example 3: Suppose blog.example.com itself has a CNAME record pointing to cust.cdn.example.net, and the validation is performed according to the process in 3.2.2.4.7. In the CNAME step, it is acceptable to replace A with cust.cdn.example.net, and in the subsequent Prune step, it is permissible to proceed to cdn.example.net and example.net. If the ADN is example.net, the validation concerns the control of example.net. Therefore, within this process, it is permitted as a MAY to validate the control of example.net, reached from the CNAME target, for the certificate associated with blog.example.com. The issue raised by the ballot page concerned the potential for expansion to any arbitrary subdomain of the name that points to it.

Example 4: If blog.example.com has the same CNAME and is validated using method 3.2.2.4.19 (ACME's HTTP challenge), the CNAME column in the table shows -, so the ADN remains blog.example.com. The scenario where the CA's HTTP request reaches the server behind the CNAME through name resolution is described separately in Section 5.4.

Example 5: When validating *.example.com and *.app.example.com, only methods that have a check (✔) in the Wildcard column can be chosen. *.example.com becomes example.com (without the wildcard), which is the Base Domain Name, so the Prune step changes nothing. *.app.example.com becomes app.example.com, and the Prune step can proceed to example.com. Since there is no CNAME step in step 4, even if app.example.com has a CNAME, this procedure does not follow it. As Section 3.2 notes, this last point is this article's reading of how the steps are written.

5. Four Kinds of CNAME in Certificate Issuance

This section identifies four distinct scenarios involving CNAME records that occur during the certificate issuance process. They differ in whose CNAME it is, who follows it, and what following it changes.

Kind	Whose CNAME	What following it changes	Where It Is Written	No Statement Found
ADN step	The applied-for FQDN itself, while it is `A` in step 3	The name whose control is validated (the ADN), only for methods with a check in the CNAME column, as a MAY	BR 2.3.1 Section 3.2.2.4, step 3.1 (checked 2026-10-28)	—
Challenge delegation	An underscore-prefixed label under the ADN, such as `_acme-challenge.<name>` or the ACM record name `_x1.<name>`	Where the challenge record is answered; the ADN does not change	BR 2.3.1 Section 3.2.2.4.7; Let's Encrypt Challenge Types; ACM ACME domain validation page	Which BR method ACM's CNAME records correspond to: no statement was found in the ACM documentation
CAA lookup	The name whose CAA records are checked	Where the CAA records are read	Linked article on CAA, Section 3.2	—
Name resolution in an HTTP method	The applied-for FQDN, when it is a CNAME to a hosting provider	Which server answers the CA's HTTP request; the ADN stays the applied-for FQDN	Let's Encrypt Challenge Types (HTTP-01); BR 2.3.1 Section 3.2.2.4 table	A sentence in the BR that addresses CNAMEs during the HTTP request: no statement was found in Sections 3.2.2.4.18 and 3.2.2.4.19

5.1 The ADN CNAME Step

The ADN CNAME step is step 3.1 of the procedure in Section 3.2. While A is the applied-for FQDN (or the result of a previous CNAME lookup), the CA may query the CNAME record for that name and replace A with the result. What this step changes is the name whose control the CA validates.

Only six methods, those listed in the table with a check in the CNAME column, have this step. As indicated in the table in Section 3.5, the CNAME queries in this step are subject to DNSSEC validation.

5.2 CNAME for Challenge Delegation

The CNAME for challenge delegation is a CNAME placed under the ADN, using labels that begin with an underscore. Section 3.2.2.4.7 of BR version 2.3.1 describes where the record is checked as follows:

Confirming the Applicant's control over the ADN by confirming the presence of a Random Value or Request Token
in a DNS CNAME, TXT or CAA record returned in a query for either:

1. the ADN; or
2. the ADN prefixed with a Domain Label that begins with an underscore character.

This method queries the selected ADN or the ADN with an underscore-prefixed label. Even when the CNAME of the underscore-prefixed label is followed, the ADN remains unchanged. What changes is the DNS zone that provides the challenge value.

The "Challenge Types" page for Let's Encrypt states the following regarding the DNS-01 challenge:

Since Let's Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use
CNAME records or NS records to delegate answering the challenge to other DNS zones.

The "ACME domain validation" page for ACM includes the following text regarding ACM's DNS validation CNAME and the ACME pre-validation CNAME.

In both cases, the CNAME delegates ongoing domain validation to ACM.

Section 3.2.2.4.7 of BR also includes the following text, pertaining to situations where the CA or a CA affiliate manages the delegated zone.

If the CA or an Affiliate of the CA operates a DNS zone to which Applicants can delegate (via CNAME) their
underscore-prefixed Domain Label, the CA MUST ensure that each Applicant delegates to a unique FQDN within
that zone. A CA or Affiliate of a CA SHOULD NOT operate such a service, and SHOULD direct any Applicants using
such a service to use the method described in Section 3.2.2.4.22 instead.

This text is a general rule of method 3.2.2.4.7. No statement was found in the ACM documentation or the ATS CP/CPS on which BR method ACM's validation CNAME corresponds to, or on whether it falls under this text (see Section 6.6). This article also does not attempt to associate ACM's CNAME with this text.

5.3 The CNAME in a CAA Lookup

CAA lookups also follow CNAME records. Section 3.2 of "What CAA Can and Cannot Stop When DNS Control Is the Weak Link" references an AWS re:Post article stating that CAA record checking follows the CNAME record, and covers which name the CAA records are read from. Following a CNAME in a CAA lookup changes where the records that say which CAs may issue are read, but it does not alter the ADN. This article will not reiterate this process.

5.4 The CNAME When the CA Resolves the Name in an HTTP Method

When using the HTTP method (3.2.2.4.18 and 3.2.2.4.19), the CNAME column in the table indicates -, so the ADN is the applied-for FQDN itself. On the other hand, the page detailing Let's Encrypt's Challenge Types lists one of the advantages of the HTTP-01 challenge as follows:

It allows hosting providers to issue certificates for domains CNAMEd to them.

These two statements are compatible. When the CA sends its request in an HTTP method, the resolution of the applied-for FQDN follows the CNAME record, ultimately reaching the hosting provider's server. At this point, the ADN remains the applied-for FQDN, and the hosting provider responds to requests for the URL associated with that FQDN. This is this article's reading of the BR table and the Let's Encrypt sentence. No statement about the CNAME in this resolution was found in the text of BR Sections 3.2.2.4.18 and 3.2.2.4.19.

In this scenario, the hosting provider may be able to obtain certificates using the HTTP method for a name that has a CNAME record pointing to their server (for example, blog.example.com). This does not extend to subdomains of that name, nor does it support wildcard names. This limitation is due to the Prune and Wildcard columns being marked as -.

5.5 Where the Ballot Background and the Method Table Disagree

The background text on the SC-101v2 ballot page includes the following line:

Only certain methods (those which perform validation at the name itself, not at a underscore-prefixed
subdomain of it) can use the "cname" step of the ADN algorithm.

According to this text, methods that validate at an underscore-prefixed label cannot use the CNAME step. However, the method table in BR version 2.3.1 indicates a check (✔) in the CNAME column for 3.2.2.4.7. As noted in Section 5.2, 3.2.2.4.7 is a method that can also validate with a record at the ADN with an underscore-prefixed label. Similarly, both 3.2.2.4.14 and 3.2.2.4.16 have a check in the CNAME column, and BR's Appendix A states that the corresponding TXT records are placed at the underscore-prefixed labels _validation-contactemail and _validation-contactphone.

The sources disagree. The background text on the ballot page and the method table in BR present conflicting information regarding the same methods. The background text serves as an explanation in the ballot, while the table and the text in BR represent the standard. This article reads the table as the basis for the procedure and will list the background text as a point of discrepancy, without stating that either is incorrect. Among the methods that validate at an underscore-prefixed label, the CNAME columns for 3.2.2.4.21 and 3.2.2.4.22 are marked with a dash (-), which aligns with the background text.

6. What the ACM Documentation Says and Does Not Say

This section compiles statements from ACM documents about the names used in domain validation, and lists which columns in the BR table they appear to correspond to. This correspondence is this article's reading; the ACM documents do not explicitly name or refer to specific methods or columns in the BR framework.

6.1 DNS Validation

The ACM User Guide's DNS validation page describes how ACM returns CNAME records during DNS validation, specifying that these values represent aliases pointing to AWS domains.

Each record, created specifically for your domain and your account, contains a name and a value. The value is
an alias that points to an AWS domain that ACM uses to automatically renew your certificate.

The table on the same page lists six examples of CNAME records. The first two rows, *.example.com and example.com, have the same record and the "Comment" column indicates "Identical." The remaining rows – www.example.com, host.example.com, subdomain.example.com, and host.subdomain.example.com – each have a "Comment" indicating "Unique." The "Record Name" in the table, excluding the *.example.com row, is a name with _xN. prepended to each individual name. The "Record Name" for the *.example.com row is the same as that of the example.com row: _x1.example.com.. The text at the top of the table states:

This illustrates that for a wildcard domain, such as *.example.com, the strings created by ACM are the same as
those created for its base domain, example.com. Otherwise, the paired Record Name and Record Value differ for
each domain name.

The ACM FAQ describes the same concept, but phrased in terms of removing wildcard labels.

Notice that ACM removes the wildcard label (*) when generating CNAME records for wildcard names. As a result,
the CNAME record generated by ACM for a wildcard name (such as *.example.com) is the same record returned for
the domain name without the wildcard label (example.com).

This description of removing wildcard labels appears to correspond to step 4.1 of the BR procedure, "Remove '*.'". However, the ACM FAQ describes how to create CNAME records, rather than how ATS selects an ADN.

The DNS validation page also states that while the CNAME record remains in place, additional certificates can be requested without repeating the validation process.

Without the need to repeat validation, you can request additional ACM certificates for your fully qualified
domain name (FQDN) for as long as the CNAME record remains in place. That is, you can create replacement
certificates that have the same domain name, or certificates that cover different subdomains.

No statement was found on which name's CNAME and which subdomains certificates that cover different subdomains refers to. The table on the same page indicates that a different record is returned for each subdomain.

Regarding CNAME chains, the following note is provided:

CNAME resolution will fail if more than five CNAMEs are chained together in your DNS configuration. If you
require a longer chaining, we recommend using email validation.

The page does not specify which CNAME scenarios in Section 5 this limitation applies to. Because ACM's CNAME records sit at underscore-prefixed labels, reading the limit as one on resolving the challenge delegation CNAME is natural, but this is this article's reading.

The AWS re:Post Knowledge Center article discusses placing ACM CNAME records in a Route 53 hosted zone associated with a different AWS account, stating that when the hosted zone is in another AWS account, CNAME records must be added manually. Similarly, an AWS Security Blog post from November 22, 2017, advises that if you are managing Route 53 DNS records in a different AWS account, you should copy the CNAME information and manually configure it in your DNS settings.

6.2 Email Validation

The ACM User Guide's Email Validation section states that when sending validation emails, the destination domain can be a superdomain of the applied-for name.

Alternatively, you can specify a superdomain as a validation domain if you wish to receive these emails at
that domain instead. Any subdomain up to the minimal website address is valid, and is used as the domain for
the email address as the suffix after @.

The same section also indicates that for names starting with www or *, ACM removes the leading label before forming the addresses.

If you request an ACM certificate for a domain name that begins with www or a wildcard asterisk (*), ACM
removes the leading www or asterisk and sends email to the administrative addresses.

The ability to select the superdomain as the destination appears to correspond to entries in the BR table where the "Prune" column for email methods is marked with a check (✔). Removing the * appears to correspond to step 4.1. The ACM documentation does not specify which methods ACM's email validation uses in the BR table. The timeline for the end of ACM's email validation is addressed in the "Moving AWS Certificate Manager Off Email Validation" document.

6.3 HTTP Validation

The HTTP validation section in the ACM User Guide, concerning certificate HTTP validation with CloudFront, highlights the following important point:

HTTP validation does not support wildcard domain certificates (such as *.example.com). For wildcard
certificates, you must use either DNS validation or email validation instead.

This aligns with the table for BR, where the Wildcard column for HTTP methods indicates -. The same section also states that the CA requests a file from the URL specified in redirectFrom, and CloudFront redirects to the URL specified in redirectTo. No statement was found in the ACM documentation on which of BR Sections 3.2.2.4.18 and 3.2.2.4.19 ACM HTTP validation corresponds to.

6.4 ACME Pre-Validation

The ACM ACME domain validation page states that for each ACME endpoint, the scope of pre-validation can be defined using three independent settings: ExactDomain (specifying the exact name), Subdomains (allowing subdomains), and Wildcards (allowing wildcard names). A table on the same page shows sub.example.com, api.example.com, and so on when only Subdomains is enabled for example.com, and *.example.com only when only Wildcards is enabled.

The same page also states that a separate CNAME record is required for each endpoint.

Each domain validation requires a CNAME record in DNS. This is the same type of CNAME record used for standard
ACM DNS validation. However, ACME domain validations are specific to individual endpoints. Different endpoints
require separate CNAME records, even for the same domain.

The distinction between Subdomains and Wildcards appears to correspond to the distinction between the Prune and Wildcard columns in the BR table. ACM documentation does not explicitly describe the relationship between these three settings and the columns in the BR table. ACME pre-validation is covered in Section 9.1 of "How AWS Certificate Manager Issues Public Certificates."

6.5 The ACM Documentation Side by Side with the BR Table

ACM statement	Appears to correspond to (this article's reading)	Where It Is Written	No Statement Found
`*.example.com` and `example.com` get identical CNAME records; ACM removes the wildcard label	Step 4.1 `Remove "*."`	DNS validation page; ACM FAQ (checked 2026-10-28)	The ADN that ATS selects for a wildcard name
Each subdomain gets a unique record, placed under that name	—	DNS validation page	Whether a validation of `example.com` is reused for a subdomain, and which records `certificates that cover different subdomains` refers to
CNAME resolution fails beyond five chained CNAMEs	Challenge delegation (Section 5.2)	DNS validation page	Which kind of CNAME the limit applies to
A superdomain can be the validation domain for email; leading `www` or `*` is removed	Prune column and step 4.1 for the email methods	Email validation page	Which BR method ACM email validation is
HTTP validation does not support wildcard certificates	Wildcard column `-` for 3.2.2.4.18 and 3.2.2.4.19	HTTP validation page; public certificate characteristics page	Which BR method ACM HTTP validation is
ACME scope settings `ExactDomain`, `Subdomains`, and `Wildcards`; one CNAME record per endpoint	Prune and Wildcard columns	ACME domain validation page	How the scope settings map to the BR columns
The hosted zone in another AWS account needs the CNAME record added manually	—	AWS re:Post Knowledge Center; AWS Security Blog (2017-11-22)	—

6.6 What Was Not Found in the ACM Documentation

For the following, no statement was found. The search included pages from Sections 6.1 through 6.4, the ACM User Guide sections on "Validate domain ownership," "public certificate characteristics and limitations," and "ACM concepts," the ACM API Reference section on "DomainValidation," the ACM FAQ, one article from the AWS re:Post Knowledge Center (regarding ACM certificate validation in Route 53), and two articles from the AWS Security Blog (regarding DNS validation from November 22, 2017, and ACME support). In addition, searches were conducted using different search terms on the AWS documentation three times.

The terms "Authorization Domain Name" and "ADN."
Which BR methods (specifically Sections 3.2.2.4.x) correspond to ACM's DNS, email, and HTTP validation processes.
Whether, for ACM validation, ATS follows the CNAME of the applied-for name (the ADN CNAME step) or prunes labels (the Prune step).
Whether ACM's validation CNAME falls under the sentence on CA-operated delegation zones in 3.2.2.4.7 quoted in Section 5.2.
An AWS announcement about SC-101v2 and the ADN change on November 15, 2026.

The ACM FAQ states that the CA/Browser Forum determines the process for verifying domain ownership, and directs users to the ATS Certification Practices Statement for more details. Section 7.1 reads that CP/CPS.

7. The Amazon Trust Services and Let's Encrypt Documents

This section sets out what the documents of Amazon Trust Services (ATS), the CA that issues ACM certificates, and of Let's Encrypt, where the proposer of SC-101v2 works, say about the ADN procedure.

7.1 ATS CP/CPS Version 2.7

ATS CP/CPS Version 2.7 (August 19, 2026) includes a section (Section 3.2.2) that lists the methods it does not use and the methods it uses.

ATS does not use the following methods described in the CABF TLS BRs: 3.2.2.4.1, 3.2.2.4.2, 3.2.2.4.3,
3.2.2.4.5, 3.2.2.4.6, 3.2.2.4.9, 3.2.2.4.10, and 3.2.2.4.11, 3.2.2.4.15.
Prior to issuance of a Subscriber certificate, ATS uses one of the following CABF TLS BR methods to validate
control of each requested DNS name: 3.2.2.4.4, 3.2.2.4.7 3.2.2.4.8, 3.2.2.4.12, 3.2.2.4.13, 3.2.2.4.14,
3.2.2.4.16, 3.2.2.4.17, 3.2.2.4.18, 3.2.2.4.19, and 3.2.2.4.20. Validations are performed by Primary Network
Perspectives and corroborated by at least the minimum quorum of Remote Network Perspectives defined in the
CABF TLS BRs effective at the time of validation.
All validations are performed in accordance with, and are compliant with, the CABF TLS BRs at the time of
validation.

The missing comma in 3.2.2.4.7 3.2.2.4.8 is in the original. This list details the methods used by ATS and does not specify which methods ACM uses for validation.

When comparing this list with BR, the following three statements are observed:

ATS CP/CPS Version 2.7 includes 3.2.2.4.8 in the list of methods it uses.
BR versions 2.2.7 and 2.3.1, both in Section 1.2.2, state that CAs MUST NOT rely on 3.2.2.4.8 from March 15, 2026.
The same section (3.2.2) of CP/CPS states that all validations are performed in accordance with the BR at the time of validation.

The transition period described in Section 3.4 is a provision on the ADN procedure and is separate from the date prohibiting reliance on 3.2.2.4.8. No statement was found regarding whether ATS used 3.2.2.4.8 after March 15, 2026. This article only sets the three statements side by side and does not call any of them an error.

The glossary in the same CP/CPS defines both ADN and Base Domain Name in the same phrasing as in BR version 2.2.7. The definition of ADN is identical to the phrasing referenced in Section 3.1, and Base Domain Name begins with "The portion of an applied-for FQDN." As stated in Section 3.4, prior to November 15, 2026, CAs may follow Section 3.2.2.4 of BR version 2.2.7. This glossary, as a document within that period, is consistent with the phrasing in BR (this article's reading; see Section 3.4). No statement was found regarding whether ATS's CP/CPS will be revised around November 15, 2026.

The interpretation of the CAA record list in Section 4.2 of ATS CP/CPS is addressed in Section 7.4 of "What CAA Can and Cannot Stop When DNS Control Is the Weak Link."

7.2 Let's Encrypt

The page detailing Let's Encrypt's Challenge Types describes the handling of wildcard certificates for both HTTP-01 and DNS-01 challenges. One drawback of HTTP-01 is stated as follows:

This challenge cannot be used to issue wildcard certificates.

One advantage of DNS-01 is stated as follows:

You can use this challenge to issue certificates containing wildcard domain names.

This matches the - in the Wildcard column for 3.2.2.4.19 in the BR table. The text regarding the delegation of DNS-01 challenges, and the statement that hosting providers can obtain certificates for names pointed to by CNAME records in HTTP-01 challenges, were referenced in Sections 5.2 and 5.4.

In the SC-101v2 vote, Let's Encrypt voted in favor, and the proposer was Aaron Gable from Let's Encrypt / ISRG. No announcements regarding SC-101v2 or the ADN change on November 15, 2026, were found on Let's Encrypt's website or community announcements. Furthermore, no statement was found regarding how Let's Encrypt's CA software selects the ADN.

8. What This Configuration Returned

This section documents the requests sent to ACM for this article, along with their responses. It is a record of this configuration on this day, not a statement in the sources. The ADN chosen by the CA cannot be observed from this record. The responses from ACM indicate the CNAME records that ACM has users place. The responses do not include information on which names ATS ultimately designated as ADNs.

8.1 Configuration

On October 28, 2026, at 21:26 UTC, a request was made to ACM in the us-east-1 region to obtain a single public certificate with DNS validation. The certificate type is non-exportable, and it includes four names. These names are the apex of the domain used for this article's test, its *. wildcard, the name www, and the name host.sub. This section writes this domain as example.com.

No CNAME records were written to DNS. Consequently, the certificate was not issued, and the status remained PENDING_VALIDATION. The reason for not issuing the certificate was to prevent the names from being logged in the Certificate Transparency logs. Eight seconds after the request, the DescribeCertificate function was called, and the DomainValidationOptions were read. At that point, all four names contained a ResourceRecord.

8.2 The Records Returned

The entries _x1 through _x6 replace strings that ACM generated, with the same number assigned to identical strings. <label-a> and <label-b> represent replacements for different labels within the Record Value.

Domain name	Record Name	Record Value	Same record as	Where It Is Written	No Statement Found
`example.com`	`_x1.example.com.`	`_x2.<label-a>.acm-validations.aws.`	`*.example.com`	`DescribeCertificate` in this configuration (2026-10-28)	—
`*.example.com`	`_x1.example.com.`	`_x2.<label-a>.acm-validations.aws.`	`example.com`	Same	—
`www.example.com`	`_x3.www.example.com.`	`_x4.<label-a>.acm-validations.aws.`	—	Same	—
`host.sub.example.com`	`_x5.host.sub.example.com.`	`_x6.<label-b>.acm-validations.aws.`	—	Same	—

Based on these records, the following five points can be observed.

Apex and wildcard records returned the same Record Name and Record Value. This matches Identical in the table on the DNS validation page, as well as the text in the ACM FAQ (Section 6.1).
For www.example.com and host.sub.example.com, different records were returned. The Record Name was a name with _xN. prepended to the requested name. This is consistent with the Unique entries in the table on the DNS validation page.
The domain in the Record Value was acm-validations.aws. The DNS validation page lists this as acm-validations.aws in the table, while the examples in the text use acm-validation.aws. Only the spelling used in the table was returned in this configuration.
The Record Value contained another label between the string created by ACM and acm-validations.aws. This label appeared in two different variations across the three records. This label is not present in the table or examples on the DNS validation page. No statement was found in the sources in Section 1.4 on what this label represents.
For all four names, the ValidationDomain matched the requested name. According to the ACM API Reference's DomainValidation page, this field represents the domain name that ACM used to send the validation email.

8.3 What This Configuration Does Not Indicate

This record does not demonstrate:

Which name ATS selects as the ADN, and whether ATS takes the CNAME step or the Prune step.
Whether a certificate for a subdomain is issued with only the apex record. This article did not write the CNAME records and did not let the certificate be issued.
Whether the same record structure will be returned in a different region, a different AWS account, or on a different day.

The certificate was deleted on October 28, 2026, at 21:29 UTC. At 21:30 UTC on October 28, 2026, the DescribeCertificate command returned a ResourceNotFoundException, and the certificate was no longer present in the list returned by ListCertificates.

9. Failure Modes

This section outlines what happens when the ADN procedure and the sources are misread.

9.1 Assuming the CNAME Target Can Get Certificates for Any Subdomain

The names for which an operator that a CNAME points to can get certificates are limited to what the procedure permits. Currently, the process does not return to the CNAME step after the "Prune" step, so there is no way to extend to any subdomain via a CNAME record for a higher-level domain, as illustrated in example 2 of Section 4.5. For the name that points to the operator with a CNAME, two things can happen: with a method that has a check in the CNAME column, the ADN can become the CNAME target (example 3 of Section 4.5), and with an HTTP method, the server at the CNAME target answers the CA's request (Section 5.4).

9.2 Assuming That Validating the Apex Covers Every Subdomain

The Prune step is only available for methods where there is a check (✔) in the Prune column, and whether to use it is the CA's choice. For HTTP and ALPN methods, validation is required for each subdomain. The table on the ACM DNS validation page shows different records for each subdomain.

9.3 Trying to Get a Wildcard Certificate with HTTP Validation

The BR table shows - in the Wildcard column for the HTTP methods, and ACM's HTTP validation page and Let's Encrypt's Challenge Types page state that HTTP validation does not support wildcards. To validate a wildcard name, you need a validation method that has a check (✔) in the "Wildcard" column.

9.4 Labeling ACM Validation with a BR Method Number

No statement was found in the ACM documentation on which BR method each ACM validation corresponds to. The list of ATS CP/CPS methods represents the methods used by ATS. Stating that the ACM DNS validation corresponds to method 3.2.2.4.7 is an inference, rather than a statement found in the documentation.

9.5 Treating the Challenge Delegation CNAME as the ADN CNAME Step

The CNAME records like _acme-challenge and ACM's _x1 point to the DNS zone responsible for responding to challenge requests. The ADN remains unchanged. Of these CNAMEs, only the ADN CNAME step changes the ADN; that step follows the CNAME of the applied-for name itself and is permitted only for methods with a check (✔) in the CNAME column (see Sections 5.1 and 5.2).

9.6 Reading a Check as What the CA Does

The ✔ indicates that something is permissible as MAY. It is not necessarily the case that the CA will follow a CNAME, prune labels, etc. (as described in Section 4.2). Similarly, interpreting November 15, 2026, as the date the CA will stop following CNAME records is also a misinterpretation.

9.7 Explaining the Old ATS Definitions and 3.2.2.4.8 for the Same Reason

This article reads the old definitions in the glossary as compatible with the BR text during the transition period, which ends on November 15, 2026. The prohibition on relying on 3.2.2.4.8 takes effect from March 15, 2026, and is outside the scope of the transition period (see Section 7.1).

9.8 Attributing Every Record-Keeping and DNSSEC Provision to SC-101v2

The provision that records include the ADN was introduced in BR version 2.2.7 (SC099) and became effective on July 15, 2026. The provision stating that CNAME queries when selecting the ADN are subject to DNSSEC validation was added in BR version 2.2.9 (SC-101v2) (see Section 3.5).

10. Frequently Asked Questions About Authorization Domain Names

This section answers common questions, referencing the sections within this article.

Q1. Starting November 15, 2026, will CAs stop following CNAMEs?

No. The CNAME step will remain in place after November 15, 2026. This step, indicated by a check (✔) in the CNAME column, is permissible as a MAY option. What will change are the following two points, which are determined in the BR body: one is the methods that may use this step, and the other is the order in which the CNAME step comes before the Prune step (see Sections 3.2 and 4.2).

Q2. If a CNAME points to a CDN, can the CDN operator get a certificate for this name?

This depends on the method and the CA's choice. In methods indicated by a check in the CNAME column, it is permissible (MAY) for the ADN to become the name the CNAME points to. In an HTTP method, the ADN remains the applied-for name, but the CA's request is delivered to the server behind the CNAME. In either case, this does not extend to any subdomains of the name that points to it (see Sections 4.5, 5.4, and 9.1).

Q3. If the apex is validated, can certificates for its subdomains be obtained without validation?

This depends on the method and the CA's choice. For methods indicated with a ✔ in the "Prune" column, using example.com as the ADN for www.example.com is permitted as a MAY. This is not permitted with HTTP or ALPN methods. The ACM documentation does not specify whether apex validation can be used for subdomains (see Sections 4.2 and 6.1).

Q4. Can a wildcard certificate be obtained through HTTP validation?

No. In the BR table, the Wildcard column for the HTTP methods is -, and both the ACM HTTP validation page and the Let's Encrypt Challenge Types page state that wildcards are not supported (Sections 4.1, 6.3, and 7.2).

Q5. Does ACM's DNS validation follow the method described in BR Section 3.2.2.4.7?

The sources do not state this. No reference to a BR method number was found in ACM's documentation. While ATS's CP/CPS lists 3.2.2.4.7 in its list of methods used by ATS, it does not specify which method ACM uses for its DNS validation (Sections 6.6 and 7.1).

Q6. If `_acme-challenge` is delegated to another zone with a CNAME, does the ADN change?

No. The CNAME delegation simply changes the zone that responds to the challenge record, after the ADN has already been determined. Of the CNAMEs, only the CNAME step for the applied-for name itself changes the ADN (see Section 5.2).

Q7. Why does ACM return the same CNAME record for both `example.com` and `*.example.com`?

The ACM FAQ states that when creating a wildcard CNAME record, the * label is removed, resulting in a record that is the same as the non-wildcard name. This appears to correspond to step 4.1 of the BR procedure (this article's reading), but it is not a statement describing the ADN chosen by ATS (Section 6.1).

Q8. Is it an error that the ATS CP/CPS carries the old ADN definition?

This article does not state that it is an error. Before November 15, 2026, CAs may follow Section 3.2.2.4 of BR version 2.2.7. Therefore, this article reads the older definitions in the glossary as compatible with BR's wording during this period. The 3.2.2.4.8 in the method list is a matter of a different date (see Sections 3.4 and 7.1).

11. Summary

From November 15, 2026, the method determines which ADNs the CA may choose.

CAs first select a method. If using an FQDN, the order is CNAME, then Prune. If using a wildcard name, the *. prefix must be removed before applying the Prune step. The CNAME and Prune steps are each optional (MAY) only when indicated by a check in the method table.
For HTTP and ALPN methods, the ADN will be the applied-for name itself, and wildcard names cannot be selected.
Before November 15, 2026, CAs may follow Section 3.2.2.4 of BR version 2.2.7. That version's definition did not specify the order of CNAME and Prune.
There are four types of CNAME usage for certificate issuance. Of the four, only the CNAME step associated with the applied-for name itself modifies the ADN. Challenge delegation, CAA lookups, and resolving names for HTTP methods do not alter the ADN.
The ACM documentation states that wildcard names and names with the *. prefix removed will return the same CNAME. HTTP validation does not support wildcards. Email validation allows sending to a superdomain. ACME pre-validation has three scopes. The term ADN and the BR method numbers were not found in the ACM documentation.
This article reads the old definitions in the glossary of ATS CP/CPS version 2.7 as compatible with the BR text during the transition period. The 3.2.2.4.8 entry in the method list should be read in conjunction with the prohibition against reliance effective March 15, 2026.

12. References

CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (docs/BR.md on the main branch)
CA/Browser Forum: Baseline Requirements, Version 2.2.7 (tag BRs/v2.2.7)
CA/Browser Forum: Baseline Requirements, Version 2.2.9 (commit ad77bf1)
CA/Browser Forum: Ballot SC0101v2: Clarify Authorization Domain Names
CA/Browser Forum: Server Certificate Working Group Ballots
GitHub: cabforum/servercert pull request #627
AWS Certificate Manager User Guide: AWS Certificate Manager DNS validation
AWS Certificate Manager User Guide: AWS Certificate Manager email validation
AWS Certificate Manager User Guide: AWS Certificate Manager HTTP validation
AWS Certificate Manager User Guide: Validate domain ownership for AWS Certificate Manager public certificates
AWS Certificate Manager User Guide: AWS Certificate Manager public certificate characteristics and limitations
AWS Certificate Manager User Guide: ACME domain validation
AWS Certificate Manager User Guide: AWS Certificate Manager concepts
AWS Certificate Manager API Reference: DomainValidation
AWS: AWS Certificate Manager FAQs
AWS re:Post Knowledge Center: How can I validate ACM certificates from Route 53?
AWS Security Blog: Easier Certificate Validation Using DNS with AWS Certificate Manager
AWS Security Blog: Automate certificates with ACME support in AWS Certificate Manager
Amazon Trust Services: Repository
Amazon Trust Services: Certificate Policy / Certification Practice Statement, version 2.7
Let's Encrypt: Challenge Types

References:
Tech Blog with curated related content

Written by Hidekazu Konishi