Question on RFC 8657 and validationmethods

[Mike Agrenius Kushner]

Hey ServerCert 

Question from our end as an implementer regarding RFC 8657 and the validationmethods parameter, as it pertains to the validation methods defined in the BRs. 

While we’ve mainly concerned ourselves with the ACME DCV methods (dns-01, http-01, tls-alpn-01), from our reading of the RFC and the BRs, the aforementioned three methods have their analogues in ca-tbr-7, ca-tbr-19, ca-tbr-20. 

Thus from our end, a couple of questions for clarification:

1. Have we understood/read the BRs/RFCs correctly in the formats for ca-tbr-*? 
2. Should ca-tbr-7 be read as a direct equivalent to dns-01 (and so on)?

Cheers,

Mike Agrenius Kushner

Senior Product Architect

EJBCA/Keyfactor

[Wayne Thayer]

Hi Mike,

I believe you are referring to ballot SC-98, which is still a draft (https://github.com/cabforum/servercert/pull/567/changes). Coincidentally, I am planning to begin the discussion period shortly.

On Thu, Apr 2, 2026 at 12:18 AM Mike Agrenius Kushner <Mike.K...@keyfactor.com> wrote:

Hey ServerCert 

Question from our end as an implementer regarding RFC 8657 and the validationmethods parameter, as it pertains to the validation methods defined in the BRs. 

While we’ve mainly concerned ourselves with the ACME DCV methods (dns-01, http-01, tls-alpn-01), from our reading of the RFC and the BRs, the aforementioned three methods have their analogues in ca-tbr-7, ca-tbr-19, ca-tbr-20.  

Correct

 

Thus from our end, a couple of questions for clarification:

1. Have we understood/read the BRs/RFCs correctly in the formats for ca-tbr-*? 
2. Should ca-tbr-7 be read as a direct equivalent to dns-01 (and so on)?

 

Section 4.2.2.1.3 states "If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. 'dns-01' and 'ca-tbr-7'), the CA SHOULD accept any of the labels as granting permission to issue." Does that answer your question?

- Wayne

[Aaron Gable]

One clarification of a subtlety: dns-01 is not quite identical to ca-tbr-7. In particular, dns-01 implements a subset of what ca-tbr-7 allows. It requires a specific underscore-prefixed label, it requires a specific token format, etc. So if someone's CAA record allows only dns-01, that should not be considered to be permission to use other DNS-based validation methods covered by ca-tbr-7. But if someone's CAA record allows only ca-tbr-7, then a CA which implements dns-01 should be fine. It's a square/rectangle situation.

Aaron

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAPh8bk-mHraqGXXYvRLx-hX_8p8DLZRn6MsDoo10d8-_Wtd%3D%2Bw%40mail.gmail.com.

[Mike Agrenius Kushner]

Hi Wayne, Aaron, 

Thanks – clarification amply provided!

Cheers,

Mike

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 2 April 2026 at 18:28
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Question on RFC 8657 and validationmethods

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErdEvPP%2BOhqve30VEYF5YeNhjGospZ%3D5LCAhMsV%3DmJ3u6A%40mail.gmail.com.

[蔡家宏(chtsai)]

Hi everyone,

 

It is common practice to use cross-signing during a Root CA transition. Typically, the legacy Root CA issues a cross-signed certificate to the new Root CA, ensuring the trust chain remains intact until the new Root CA is widely adopted in all browser trust stores.

 

However, based on Microsoft’s documentation (https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails) and our actual testing, this cross-signing mechanism fails when using IIS. This occurs because the operating system invariably selects the shortest path, preventing the mechanism from achieving its intended effect.

 

Following Microsoft's recommendation requires the server to "temporarily" distrust the "new Root CA," which leads to further issues—such as determining when to revert this setting. After all, intentionally distrusting a new Root CA is a rather unconventional approach.

 

I would like to ask if anyone has encountered similar issues and how you resolved them? Are there any other mitigation measures available?

 

Any insights or shared experiences from the community would be greatly appreciated.

Thank you in advance for your time and expertise.

 

Best regards,

CyhaHung Tsai

[Mark Gamache]

I have dealt with this a few times. You must distrust or remove the root from all stores. 

Get Outlook for Android

---

From: '蔡家宏(chtsai)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, April 9, 2026 5:56:22 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Issues with IIS choosing the "Shortest Path" and breaking Cross-Signed Certificate chains

 

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/d9e44acf06d04a709c5ea0f6f7b124a8%40twca.com.tw.

[蔡家宏(chtsai)]

Apologies, I accidentally replied to the wrong thread. I am starting a new one now.

 

------

[大野 文彰]

Hi CyhaHung, all,

 

We have experienced the same behavior on IIS / Windows, and in our case we have basically followed the approach described in Microsoft’s documentation, including the “temporary distrust” guidance.

 

The key point is that this issue is not specific to any particular CA, but rather stems from Windows behavior itself: during path building and server-side certificate presentation, Windows consistently prefers the shortest available certification path.

 

When a self-signed Root path and a cross-signed Root path coexist on an IIS server, IIS may present the shorter path, even though that path is not usable by non-Microsoft browsers. As a result, even if the cross-root certificate itself is correctly issued and installed on the IIS server, the required cross-signed chain is not presented to Chrome, Apple platforms, or Firefox, leading to certificate chain construction failures.

 

To address this, we adopted a mitigation approach that explicitly controls which certificate paths are available on the IIS server.

 

Specifically, we do the following:

 

- Remove or disable the root certificate that forms the “short” (self-signed) path — typically a newer Root CA that is not yet trusted by non-Microsoft browsers — from the server, so that IIS can only build chains via the cross-signed path.

- Keep the cross-signed Root certificate and the required intermediate certificates, ensuring that IIS can construct and present only the intended certificate chain.

 

With this approach, IIS is prevented from selecting an incorrect chain, without requiring any changes to client-side trust settings.

 

We have also documented related operational steps, such as:

- Verifying the presented chain using `openssl s_client`

- Restarting IIS or the OS to reload the certificate store

- Disabling automatic root updates to prevent unwanted certificates from being restored automatically

 

As for when to revert this configuration, we consider the appropriate timing to be when the new Root CA has been fully distributed into the trust stores of major browsers and operating systems. Even if the cross-root configuration remains in place longer than strictly necessary, modern clients (web browsers) will generally construct the shortest valid trust path on the client side, so we believe the residual risk is relatively low.

 

While this approach is admittedly not elegant, it has proven to be a stable and reproducible workaround in real-world IIS environments. If anyone has found a cleaner or more deterministic solution on Windows / IIS, we would greatly appreciate it being shared.

 

Best regards,

 

ONO Fumiaki / 大野 文彰

(Japanese name order: family name first, in uppercase)

SECOM Trust Systems CO., LTD.

 

From: '蔡家宏(chtsai)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, April 10, 2026 10:07 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Issues with IIS choosing the "Shortest Path" and breaking Cross-Signed Certificate chains

 

Apologies, I accidentally replied to the wrong thread. I am starting a new one now.

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/07f73e9711c648a187fc6b4d38443593%40twca.com.tw.

[大野 文彰]

Hi CyhaHung, all,

 

I also realized that I replied to the wrong thread earlier.

Since a new thread has been created, I’ve reposted my comments there as well, and I think it would be better to continue the discussion in that thread.

https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/IV5e-Rr_LFo/

 

Best regards,

 

ONO Fumiaki / 大野 文彰

(Japanese name order: family name first, in uppercase)

SECOM Trust Systems CO., LTD.

 

From: 大野 文彰

Sent: Friday, April 10, 2026 3:03 PM
To: 'server...@groups.cabforum.org' <server...@groups.cabforum.org>

[Mark Gamache]

When you choose cross-signing, you choose pain and complexity.  You have to accept the tradeoffs.

The more common and less painful direction is the opposite. You have a root CA, but getting it trusted by browsers and OSs is taking too long. You get it x-singed by an already trusted root. Then, later when the CA is explicitly trusted, you shorten the chain.  Windows does it for you, and on other platforms it probably doesn't, but it doesn't matter, as the chain validates at the real root of the x-singed root. 

Cheer,

Mark Gamache 

---

From: 大野 文彰 <fumi...@secom.co.jp>
Sent: Thursday, April 9, 2026 11:10 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] RE: Issues with IIS choosing the "Shortest Path" and breaking Cross-Signed Certificate chains

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/OSOP286MB7648F13685DB9D9E2BB030E9AE592%40OSOP286MB7648.JPNP286.PROD.OUTLOOK.COM.

[Aaron Gable]

The problem arises when Microsoft trusts a new root before other trust stores do.

If an IIS server trusts only the old root, and handles a request from a Chrome client that already trusts the new root, everything works. IIS serves a longer-than-necessary chain, but that's fine.

If both IIS and Chrome trust the new root, or neither trusts the new root, then of course things work as well.

But when IIS trusts the new root (and therefore serves a short chain), while Chrome does not yet trust the new root (and therefore needs the longer chain), that's when you run into difficulties.

The solution, however terrible, seems to be to apply for inclusion in all root programs except for Microsoft, and then only apply for inclusion in the Microsoft root program after you believe that relying party trust stores have been largely updated. This may take years, as some clients are very slow to update. The better solution, of course, is to fix IIS.

On Fri, Apr 10, 2026 at 10:21 AM Mark Gamache <ma...@markgamache.com> wrote:

When you choose cross-signing, you choose pain and complexity.  You have to accept the tradeoffs.

Note that no one is "choosing" cross-signing. Having a cross-signature from your previous root is mandatory per the Chrome Root Program Requirements.

Aaron

[Martijn Katerbarg]

Hi Mark,

>Then, later when the CA is explicitly trusted, you shorten the chain.  

While true in theory, practice shows that it’s not as simple. We keep seeing replying parties with older devices that just won’t ever get that new CA. These usually can be devided into two categories:

• Custom devices, which really shouldn’t be using Public CA/WebPKI anyways
• Older smartphones, which do validly use the WebPKI, but are on devices no longer receiving firmware updates. For these, that’s a real concern. 

Aaron,

>The better solution, of course, is to fix IIS.

+Azure. Some Azure apps suffer from the same issue, and for those, the IIS workaround unfortunately does not work. 

Regards,

Martijn

From: 'Aaron Gable' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 10 April 2026 at 20:37
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Re: Issues with IIS choosing the "Shortest Path" and breaking Cross-Signed Certificate chains

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAEmnErcD_Bp-0Jcwi6c%3DVDdptKTmu0Of-%3Dgfrc%2BYPEqcSuY3oA%40mail.gmail.com.