Question about IIS choosing the "Shortest Path" and breaking Cross-Signed Certificate chains
蔡家宏(chtsai)
Apologies once again. I am resending this with a revised subject line. 😅
Thank you for the response, Mark.
My concern is that this approach could cause significant inconvenience for users—especially as the old Root approaches expiration, as we would then need to notify users to revert their settings.
--------
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
Brandi Hinojosa
--
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/91eb27d979684909b05c42c521f1bc8f%40twca.com.tw.
大野 文彰
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.
--