Authorization Domain Names: Which Name Your CA Actually Validates

What an Authorization Domain Name is

The Baseline Requirements define it in one line: the FQDN used to perform validation of domain authorization or control for a given FQDN or Wildcard Domain Name. In plain terms, it is the name the CA points its check at. Request a certificate for shop.example.com and the CA may, depending on how it validates, run that check against example.com instead and treat the result as authorising the subdomain. That substituted name is the Authorization Domain Name, or ADN.

This is the mechanism behind a behaviour most administrators have relied on without naming it. One _acme-challenge TXT record at the apex covering every hostname beneath it is ADN pruning. A wildcard certificate issued after a single DNS check is ADN pruning. The convenience was never a courtesy from the CA — it was a permission in the rules, and until 2026 that permission was written as part of a dictionary definition rather than as a procedure.

That placement caused the problem SC101 set out to fix. A definition that also carries normative instructions leaves genuinely open questions: may the steps be repeated, may they be combined, must they happen in a particular order? Different CAs read it differently, and a rule that two auditors can read two ways is not much of a rule.

The five steps a CA follows

Section 3.2.2.4 now states the process the CA MUST follow when choosing the ADN for each applied-for name. Initialise a working value to the applied-for FQDN or Wildcard Domain Name. Choose a validation method. If the working value is an FQDN, optionally replace it with a CNAME lookup result and optionally prune leftmost labels, each step allowed only if the method permits and each repeatable. If it is a wildcard, strip the *. first, then optionally prune. Whatever remains is the ADN.

Two details in that sequence carry most of the weight. The first is that pruning stops at the Base Domain Name — the first label to the left of a public suffix, so example.com or example.co.uk. A CA may not climb to com and validate there, which is the guardrail that stops one registrant from authorising an entire top-level domain.

The second is the ordering. The CNAME step is listed before the pruning step, and the text presents them as numbered steps rather than as a menu. A CA following the sequence literally may follow CNAMEs and then prune, but not prune and then start following CNAMEs from the shortened name. Under the old definition that question had no clear answer, which is precisely the ambiguity the ballot was written to close.

Which methods may prune or follow CNAMEs

The permissions now live in a table, one row per validation method, four columns: Wildcard, Prune, CNAME and Onion. A method may do only what its row permits. As of the Baseline Requirements in force in September 2026, thirteen rows are listed, and the three highlighted below are the ones that behave differently from everything else.

Those three highlighted rows carry no permission at all except the last one. They cannot cover a wildcard, cannot prune, cannot follow a CNAME, and they are the only three methods that may validate an .onion name. The next section is about why.

One row pair is easy to misread. The two newest DNS methods, dns-account-01 and the persistent TXT record introduced for long-lived delegations, may prune but may not follow a CNAME. Both already bind their record to a specific account, so allowing a CNAME indirection on top would add a second moving part to a design built to remove one.

Why HTTP validation cannot climb

Because serving a file proves less than publishing a DNS record. The reasoning goes back to Ballot SC045 in 2021, which observed that HTTP-based methods demonstrate control over a particular host and service rather than over the entire domain namespace. Anyone who can upload a file to one web server can pass an HTTP check for the name that server answers to. That is not the same as controlling the zone, and it should not be allowed to speak for names the uploader may have nothing to do with.

The concrete case is a shared platform. Suppose blog.example.com is a CNAME to a hosting provider where customers can publish arbitrary files. If HTTP validation could prune, a tenant on that platform could pass a check for blog.example.com, have the CA climb to example.com, and obtain a certificate for the whole estate. Blocking the climb keeps the blast radius equal to the thing the tenant genuinely controls.

For most people this is invisible, because most ACME clients already request http-01 per name and serve the challenge on that name. It becomes visible in two places: manual DCV through a CA portal where a single file upload was once accepted for a list of hostnames, and platform integrations that validate a customer apex once and issue for subdomains later. Both patterns need a DNS-based method to keep working.

The missing CNAME step for wildcards

Read the process carefully and one asymmetry stands out: the CNAME step exists only in the branch for plain FQDNs. The wildcard branch has two steps, remove the *. and optionally prune, and no CNAME substitution at all. So even under method 3.2.2.4.7, which carries a CNAME check in its row, a CA deriving an ADN for *.example.com may not follow a CNAME to get there.

This is worth separating from something that looks similar and is completely unaffected. Delegating _acme-challenge.example.com by CNAME to a dedicated validation zone is not ADN derivation — the ADN is still example.com, and the CNAME is resolved by ordinary DNS when the CA queries for the TXT record. That pattern continues to work for wildcards exactly as before. What the rules close off is CNAMEing the certified name itself and expecting the CA to validate wherever it lands.

Combined with the Wildcard column, the practical rule is short enough to remember: a wildcard is only ever provable through DNS, email or phone contact methods, and only on the name itself or a parent up to the Base Domain Name. If your automation issues wildcard certificates today, it is already using a DNS method, and nothing about this section should change it.

What changes on 15 November 2026

The optionality ends. Section 3.2.2.4 currently opens by saying that prior to 2026-11-15 a CA may adhere either to the current text or to Section 3.2.2.4 of Baseline Requirements version 2.2.7, and that effective 2026-11-15 the CA SHALL adhere to the current text. Until then two CAs can answer the same validation request differently and both be compliant; afterwards there is one process.

SC101 was adopted on 2 July 2026 and took effect on 6 August 2026 as Baseline Requirements v2.2.9. The Forum describes the algorithm as matching the most common reading of the old definition, so this is not expected to disrupt most CAs, and it should not disrupt most subscribers either. The exposure is concentrated in whatever your CA was doing under the looser reading, which is not something you can determine from the ballot text — only from your own renewal logs.

There is a second source of surprises, and it is not the rules. A good deal of the CA and reseller documentation currently ranking for this topic still describes domain control validation the old way: the authority tries the applied-for name, then strips a label and tries again, repeating until it reaches the registrable domain, with no mention that the method chosen decides whether it may do any of that. Several of those pages describe the sequence specifically for HTTP-based validation, which is one of the three methods that may not prune at all. Check the rules, not the knowledge base article.

What to check in your own setup

Look for any place where a validation performed against one name is being relied on to issue for a different name. That is the whole exposure. Four checks cover nearly all of it, and all four are quicker to run now than to diagnose during a renewal failure in late November.

• Find HTTP validation covering subdomains. If a CA portal or an internal tool validates an apex over HTTP and then issues for hostnames beneath it, move that domain to a DNS-based method before mid-November.
• Confirm wildcards are validated through DNS, not HTTP. A wildcard order that has been passing an HTTP check is running on a reading of the rules that expires.
• Check for CNAMEs on certified names. Following a CNAME on the name itself is permitted for seven methods and never for a wildcard. Delegating an underscore-prefixed challenge label is unaffected and needs no change.
• Fix your own runbooks. Any internal procedure written before August 2026 probably tells an operator to try the parent domain when validation fails. After mid-November that advice will send someone down a path their CA can no longer accept.

One closing note on where the risk actually sits. Nothing here touches a certificate you already hold, and no browser behaviour changes on 15 November. The failure mode is quiet: an automated renewal that has worked for years returns a validation error, and because certificate lifetimes are falling at the same time, the gap between the rule taking effect and your pipeline noticing may be measured in weeks. Checking now costs an afternoon.