Examples for discussion of PR 627 (ADN Draft Ballot)

[Aaron Gable]

Hi all,

As discussed at the last Validation WG meeting, here are two worked examples demonstrating why allowing validation reuse at the ADN level is both safer and more desirable than the current status quo, which is allowing validation reuse at the requested-FQDN level. For context, I’ve included both the existing BRs text and the relevant portions of the draft ballot text.

Text from the Current BRs (v2.2.2)

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 CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table...

Proposed text from PR 627 (ADN Ballot)

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

[...]

3. If `A` is an FQDN:

    1. Optionally, if the validation method has a check in the CNAME column below, 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, prune zero or more Domain Labels of `A` from left to right until `A` is equal to the Base Domain Name of `A`, or the CA chooses to stop pruning, whichever comes first.

[...]

(same as current BRs:) The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table...

Scenario 1

An Applicant wants two certificates, one for blog.example.com and one for admin.example.com. They will perform validation using Method 7 (DNS Change). No CNAMEs are involved.

Under the current BRs

For the first certificate, the CA chooses to prune a label and use example.com as an ADN. They complete validation at that ADN. They now have a reusable validation for blog.example.com. For the second certificate, they follow the same process, since they are not able to reuse their previously-cached validation.

Under the draft ballot

For the first certificate, the DNS Change method allows pruning during ADN selection, so the CA elects to use example.com as the ADN. They complete validation at that ADN. They now have a reusable validation for example.com. For the second certificate, they follow the same ADN selection algorithm, and reuse the cached validation for that ADN.

This is an improvement over the current BRs, because more validations become reusable. Today, if a CA used example.com as the ADN for both blog.example.com and admin.example.com, but only performed validation once (i.e. reused a validation of one name for the other), they would be in violation of the Baseline Requirements.

Scenario 2

An applicant wants two certificates, one for example.com and one for admin.example.com. The main website is actually a CNAME to example-com.sitehost.com.

Under the current BRs

For the first certificate, the CA chooses to follow the CNAME to example-com.sitehost.com, then prune a label and perform validation at the sitehost.com ADN. They now have a reusable validation for example.com. For the certificate for the admin subdomain, the CA prunes a label, sees that they already have a cached validation for example.com, and reuses that validation.

This is a security issue, because example.com was validated via control of sitehost.com. Control of that CDN does not imply control over admin.example.com, so that CDN operator could now get certificates for arbitrary subdomains of their customer’s domain, which they do not actually control.

Under the draft ballot

For the first certificate, the DNS Change method allows CNAME following and pruning during ADN selection, so the CA chooses sitehost.com as the ADN to validate. They now have a reusable validation for sitehost.com. For the certificate for the admin subdomain, they have to perform a second validation, since the same ADN cannot be selected.

The concern expressed in the call is that it seems surprising for the subscriber to now have a validation for sitehost.com, which they could presumably use to get certificates for other subdomains of that hosting provider. And I would agree that this would be surprising if the subscriber were the operator of example.com, but they aren’t: by virtue of the fact that they were able to complete validation at the root of sitehost.com, we know that the subscriber is actually the operator of that hosting provider. Giving that subscriber a reusable validation makes perfect sense.

Thanks, I’m looking forward to the discussion tomorrow,

Aaron

[Dimitris Zacharopoulos (HARICA)]

Hi Aaron and Jacob, this email was helpful to understand how difficult it must be for implementers and auditors to follow what's in the current BRs. Before proposing changes, we must consider the risks and challenges of Domain Validations, delegations and the DNS specifics, basically redo the security exercises performed years ago when these methods were first documented.

See my comments below.

On 2/4/2026 9:45 PM, 'Aaron Gable' via Validation Subcommittee (CA/B Forum) wrote:

Hi all,

As discussed at the last Validation WG meeting, here are two worked examples demonstrating why allowing validation reuse at the ADN level is both safer and more desirable than the current status quo, which is allowing validation reuse at the requested-FQDN level. For context, I’ve included both the existing BRs text and the relevant portions of the draft ballot text.

Text from the Current BRs (v2.2.2)

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 CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table...

Proposed text from PR 627 (ADN Ballot)

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

[...]

3. If `A` is an FQDN:

    1. Optionally, if the validation method has a check in the CNAME column below, 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, prune zero or more Domain Labels of `A` from left to right until `A` is equal to the Base Domain Name of `A`, or the CA chooses to stop pruning, whichever comes first.

[...]

(same as current BRs:) The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself within the maximum number of days prior to issuing the Certificate, as defined in the following table...

Scenario 1

An Applicant wants two certificates, one for blog.example.com and one for admin.example.com. They will perform validation using Method 7 (DNS Change). No CNAMEs are involved.

Under the current BRs

For the first certificate, the CA chooses to prune a label and use example.com as an ADN. They complete validation at that ADN. They now have a reusable validation for blog.example.com. For the second certificate, they follow the same process, since they are not able to reuse their previously-cached validation.

It's the same Applicant who has demonstrated control of the "example.com" Domain Namespace. Why is this validation not re-usable for blog.example.com? I believe this is allowed by the current BRs. The "validated FQDN" was an ADN which was "example.com".

Under the draft ballot

For the first certificate, the DNS Change method allows pruning during ADN selection, so the CA elects to use example.com as the ADN. They complete validation at that ADN. They now have a reusable validation for example.com. For the second certificate, they follow the same ADN selection algorithm, and reuse the cached validation for that ADN.

This is an improvement over the current BRs, because more validations become reusable. Today, if a CA used example.com as the ADN for both blog.example.com and admin.example.com, but only performed validation once (i.e. reused a validation of one name for the other), they would be in violation of the Baseline Requirements.

I disagree. I believe it's exactly the same thing as with the current BRs. If the CA uses "example.com" as an ADN, as described in 3.2.2.4.7. that validation can be re-used for the entire Domain Namespace of "example.com".

Scenario 2

An applicant wants two certificates, one for example.com and one for admin.example.com. The main website is actually a CNAME to example-com.sitehost.com.

What is this "main website"? "example.com" cannot have a CNAME, only A record can wrk. Shall we assume it's "www.example.com" instead of "example.com"?

Under the current BRs

For the first certificate, the CA chooses to follow the CNAME to example-com.sitehost.com, then prune a label and perform validation at the sitehost.com ADN. They now have a reusable validation for example.com. For the certificate for the admin subdomain, the CA prunes a label, sees that they already have a cached validation for example.com, and reuses that validation.

This is a security issue, because example.com was validated via control of sitehost.com. Control of that CDN does not imply control over admin.example.com, so that CDN operator could now get certificates for arbitrary subdomains of their customer’s domain, which they do not actually control.

Actually, no. If the Domain Administrator of "example.com" delegates the entire Domain Namespace via CNAME (e.g. by adding _myredirection.example.com CNAME example-com.sitehost.com), this means the DNS administrator of "example-com.sitehost.com" can add a TXT/CAA/CNAME to satisfy the DCV for the entire Domain Namespace of example.com.

The validation would work as follows:

1. Applicant asks for blog.example.com and decides to add _myredirection.example.com as the ADN (probably under the directions of the CA)
2. Applicant has a CNAME record _myredirection.example.com pointing to example-com.sitehost.com
3. The CA uses _myredirection.example.com which effectively is for "example.com" because it's ok to prefix with a Domain Label that begins with an underscore character
4. The CA follows that CNAME and gets example-com.sitehost.com
5. Now, there are two interpretations:
1. That's it. No more pruning, etc. The CA now checks the challenges (TXT, CAA, CNAME) in example-com.sitehost.com.
2. More pruning is allowed. The CA picks the ADN "sitehost.com" and searches for the challenges (TXT, CAA, CNAME) in sitehost.com
6. If the challenge is met, blog.example.com is validated but so is the entire Domain Namespace of "example.com" which means the Applicant can now request "admin.example.com, www.admin.example.com, sub1.sub2.sub3.example.com, *.sub1.sub2.example.com" and so on".

I'd be very interested to know if there is a different reading of the current BRs. Effectively, the DNS administrator that controls "example-com.sitehost.com" or "sitehost.com" can demonstrate control of the entire Domain Namespace of "example.com" because the Domain Owner of "example.com" added an underscore-prefixed label right before the Base Domain Name, and CNAMEd that to a hosting provider.

Here's another common scenario:

1. Applicant wants to issue for www.example.com and adds a CNAME pointing to the hosting provider "example-com.sitehost.com"
2. The ADN is www.example.com. The CA follows the CNAME and then prunes the left-most label ending up with "sitehost.com"
3. The CA checks "sitehost.com" for TXT, CAA, CNAME records to find the challenge
4. The Domain is validated but only for all the labels "www.example.com" (i.e. sub1.sub2.www.example.com, *.sub1.sub2.www.example.com, and so on).

To the best of my understanding, validating www.example.com with a CNAME originating from www.example.com, does not allow the hosting provider (DNS administrator of sitehost.com") to validate any random domain under example.com.

Thoughts?

Dimitris.

Under the draft ballot

For the first certificate, the DNS Change method allows CNAME following and pruning during ADN selection, so the CA chooses sitehost.com as the ADN to validate. They now have a reusable validation for sitehost.com. For the certificate for the admin subdomain, they have to perform a second validation, since the same ADN cannot be selected.

The concern expressed in the call is that it seems surprising for the subscriber to now have a validation for sitehost.com, which they could presumably use to get certificates for other subdomains of that hosting provider. And I would agree that this would be surprising if the subscriber were the operator of example.com, but they aren’t: by virtue of the fact that they were able to complete validation at the root of sitehost.com, we know that the subscriber is actually the operator of that hosting provider. Giving that subscriber a reusable validation makes perfect sense.

Thanks, I’m looking forward to the discussion tomorrow,

Aaron

--
You received this message because you are subscribed to the Google Groups "Validation Subcommittee (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validation+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/validation/CAEmnEreXwZ_st2cKB4827mv-WkUXjLh52fwD8ELFrLVpEifdaQ%40mail.gmail.com.

[Aaron Gable]

Hi all,

Thanks for these responses, and for the discussion in the WG call this morning. I've created a shared google doc for easier collaboration, and linked to it from the Forthcoming Agenda Items wiki page.

Additional thoughts, largely just repeating what was said in the call, in-line below:

On Sat, Feb 14, 2026 at 4:32 AM 'Dimitris Zacharopoulos (HARICA)' via Validation Subcommittee (CA/B Forum) <valid...@groups.cabforum.org> wrote:

It's the same Applicant who has demonstrated control of the "example.com" Domain Namespace. Why is this validation not re-usable for blog.example.com? I believe this is allowed by the current BRs. The "validated FQDN" was an ADN which was "example.com".

Actually, I believe you're right. I was doing too strict of a reading here. As I said in the call, one of the goals of the draft ballot is to make this explicitly clear. 

Scenario 2

An applicant wants two certificates, one for example.com and one for admin.example.com. The main website is actually a CNAME to example-com.sitehost.com.

What is this "main website"? "example.com" cannot have a CNAME, only A record can wrk. Shall we assume it's "www.example.com" instead of "example.com"?

You're right that example.com can't have a CNAME, because it is a DNS zone cut and therefore needs NS records. But the point of this scenario is that one of the domains is a subdomain of the other, so we could work with "mysub.example.com" and "admin.mysub.example.com" and the scenario would work exactly the same.

 

Under the current BRs

For the first certificate, the CA chooses to follow the CNAME to example-com.sitehost.com, then prune a label and perform validation at the sitehost.com ADN. They now have a reusable validation for example.com. For the certificate for the admin subdomain, the CA prunes a label, sees that they already have a cached validation for example.com, and reuses that validation.

This is a security issue, because example.com was validated via control of sitehost.com. Control of that CDN does not imply control over admin.example.com, so that CDN operator could now get certificates for arbitrary subdomains of their customer’s domain, which they do not actually control.

Actually, no. If the Domain Administrator of "example.com" delegates the entire Domain Namespace via CNAME (e.g. by adding _myredirection.example.com CNAME example-com.sitehost.com), this means the DNS administrator of "example-com.sitehost.com" can add a TXT/CAA/CNAME to satisfy the DCV for the entire Domain Namespace of example.com.

You're now talking about a very different scenario, we'll call it "Scenario 3", in which the CNAME delegation is happening on an underscore-prefixed subdomain rather than on the domain itself. This is very different, and I'll add a section to the google doc linked above to discuss this scenario in detail. Short version: it is still fully supported under the draft ballot.

Thanks again,

Aaron