Hello,
We are investigating an issue with a legacy website opened in Microsoft Edge IE mode.
The website works correctly on Active Directory domain-joined devices, but it does not work on Microsoft Entra ID joined and Intune-managed devices.
Environment
- Windows 11
- Microsoft Edge with IE mode enabled
- Enterprise Mode Cloud Site List managed through Microsoft 365
- Working devices: Active Directory domain joined
- Affected devices: Microsoft Entra ID joined and Intune managed
- The website requires a client certificate
- The affected URL uses a redirect page and opens the actual business page in a new window
The URL structure is similar to the following:
https://example.example.com/.../SETCK2/redirect.html
The redirect page then opens a URL similar to:
https://int.bts.com/todfmdfgdg-fdfdo/dfw/SP/web/uj_startFromTNetGet.html
The actual URLs contain temporary Session, TS and business parameters, which have been omitted here.
Behavior on an AD domain-joined device
- The user opens the link.
- The client certificate is applied automatically.
- A new business application window opens.
- The application loads successfully.
Behavior on a Microsoft Entra ID joined device
- The user opens the same type of link.
- A client certificate selection dialog is displayed.
- The user selects and confirms the certificate.
- A new IE mode page appears very briefly.
- The page immediately disappears.
- The business application does not remain open.
Cloud Site List configuration
We have already added both the redirect page path and the destination business page path to the Cloud Site List as IE mode sites.
The following configuration was tested:
Open in: IE mode
Compatibility mode: Default
Allow Redirect: Yes
The SAML/SSO paths were configured as Neutral Sites:
Open in: None
The Cloud Site List was published, and the new version and entries were confirmed on the affected device in:
edge://compat/enterprise
Force Update was also performed on the test device.
Adding the destination URL to the Cloud Site List did not change the behavior.
CAPI2 certificate-chain errors
After clearing the CAPI2 Operational log and reproducing the issue, we found an error similar to:
0x800B010A
CERT_TRUST_IS_PARTIAL_CHAIN
The certificate chain could not be built to a trusted root authority.
However, we performed the same test on an AD domain-joined device that successfully opens the application.
The same certificate-chain error is also recorded on the working AD device.
Therefore, we currently believe that this CAPI2 error is not the direct cause of the problem, or at least it is not the difference that determines whether the application opens successfully.
We have not deployed any additional root or intermediate certificate through Intune because the same chain-building error occurs on both the working and non-working devices.
IEChooser results
We tried using:
%systemroot%\system32\f12\IEChooser.exe
Before the certificate is selected, IEChooser remains blank even after refreshing.
After the certificate is confirmed, an IE mode page appears in IEChooser only briefly and then disappears immediately, so we are unable to attach to it and inspect the Network or Console information.
This suggests that the new IE mode window is created, but it is closed almost immediately.
Important difference between the two environments
The most significant difference currently identified is the client certificate behavior:
AD domain-joined device:
The certificate is applied automatically, and the application opens successfully.
Microsoft Entra ID joined device:
The certificate selection dialog is displayed, and the application window closes after the certificate is selected.
We have not yet confirmed whether the AD device is receiving one of the following settings through GPO:
AutoSelectCertificateForUrls
It is also possible that the AD device has only one matching client certificate, while the Entra ID device has multiple eligible certificates.
Causes that appear less likely based on the current tests
The following items have been tested or appear less likely:
- The redirect URL was missing from the Cloud Site List The
SETCK2 redirect path is already configured and is opening in IE mode.
- The destination business URL was missing from the Cloud Site List The destination
SP/web/uj_startFromTNetGet.html path was added, published and confirmed, but the behavior did not change.
- The Cloud Site List was not updated on the device The latest version and entries were confirmed in
edge://compat/enterprise.
- The CAPI2 partial-chain error alone is causing the failure The same error is recorded on the working AD domain-joined device.
- The new business window is never created A page appears briefly after the certificate is selected, although it closes too quickly to inspect with IEChooser.
Questions
Could you please advise on the following?
- Can a difference in client-certificate automatic selection cause an IE mode application window to close immediately after certificate selection?
- For an IE mode website, should client-certificate automatic selection be configured through the Microsoft Edge policy below?
AutoSelectCertificateForUrls
Or is the behavior mainly controlled by the Internet Explorer security-zone setting below?
Don't prompt for client certificate selection when no certificates or only one certificate exists
- Does IE mode require the Edge frame process and the IE mode process to select the same client certificate? Could a manual certificate prompt cause the certificate to be unavailable to the newly opened IE mode window?
- Are there any additional policies that normally need to be migrated from GPO to Intune for this scenario, such as:
Site to Zone Assignment List
InternetExplorerIntegrationSiteRedirect
SendIntranetToInternetExplorer
PopupsAllowedForUrls
AutoSelectCertificateForUrls
- What is the recommended way to capture diagnostic information when the IE mode window exists for only a few seconds and disappears before IEChooser can attach to it?
- Is there an ETW provider, netsh trace scenario, ProcMon filter or Microsoft-supported diagnostic tool that can capture:
- the client certificate selected,
- the destination URL,
- the HTTP/TLS result,
- and the reason the IE mode window closes?
- Since the same CAPI2 partial-chain event occurs on the successful AD device, is it reasonable to treat that event as unrelated or non-blocking in this case?
Any advice on which GPO, Intune, IE security-zone or client-certificate settings should be compared between the AD and Entra ID joined devices would be appreciated.
Thank you.
<Moved from: Microsoft Edge | Website issues | Windows 10>