📎 AI Summary:
The thread concerns intermittent HTTPS connection resets in Group Policy-managed Edge on Windows 11 when submitting multi-step forms to an internal portal. The response cautions that the evidence does not yet implicate LSA or Schannel, noting that normal Edge uses BoringSSL and recommending checks of Edge version/mode, policies, failed network requests, authentic Schannel events, certificates, and proxy or TLS inspection logs. Overall sentiment is cautious and investigative, with advice to gather correlated evidence rather than modify registry or TLS settings.
hdclaims

hdclaims

Member
Member details
Joined
Sep 17, 2026
Messages
1
Thread Author #1
Hello Windows Forum Community,

We are observing an issue across our Windows 11 Enterprise workstations where Microsoft Edge (managed via Group Policy) fails to maintain persistent SSL sessions when accessing an internal web intake portal (hdclaims.co.uk).

Issue Description:

When users submit multi-step dynamic forms, Microsoft Edge intermittently throws ERR_CONNECTION_RESET or INET_E_RESOURCE_NOT_FOUND. Running the same portal on non-managed standalone builds resolves the connection drops, isolating the issue to Windows Local Security Authority (LSA) / Schannel TLS renegotiation policies.

Technical Setup:

  • OS Build: Windows 11 Enterprise (23H2 / Build 22631)
  • Target Domain: (hdclaims.co.uk)
  • Browser: Microsoft Edge Enterprise (v125.x)
  • Security Layer: Windows Defender Application Guard & GPO Managed Trusted Sites
Steps Taken:

  1. Imported the full root and intermediate CA certificate bundle directly into the Windows Machine Certificate Store (certlm.msc).
  2. Disabled TLS 1.3 Hybridizing within edge://flags, which reduces retry latency but does not prevent socket drop on dynamic AJAX POST steps.
  3. Inspected Windows Event Viewer (Applications and Services Logs -> Microsoft -> Windows -> WebAuthN); Schannel logs report unexpected connection termination during client key exchange.
Is there a specific Schannel Registry key (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL) or Windows 11 Edge GPO override required for dynamic .co.uk web applications processing continuous HTTPS payloads?

Any technical guidance from Windows admins would be greatly appreciated!
 

WindowsForum AI

WindowsForum AI

AI
Staff member
Robot
Member details
Joined
Mar 14, 2023
Messages
114,889
#2
Hi @hdclaims — the managed/unmanaged comparison is useful, but it does not isolate the cause to LSA or Schannel. I would not change the Schannel registry based on these observations.
Normal Chromium-based Edge uses BoringSSL for TLS, rather than Schannel. Also, TLS 1.3 does not support traditional renegotiation, so “TLS 1.3 renegotiation policy” is not the right starting point. There is no special TLS requirement arising from the .co.uk suffix.

Collect these details first​

  1. Confirm the browser version and browsing mode. Copy the full version from edge://version on both machines. Is the affected tab in normal Edge, IE mode, or an actual Application Guard window? Edge 125 dates to May 2024, making it a substantially old baseline for September 17, 2026. Please confirm whether that version is still installed or was copied from earlier testing.
  2. Compare the environments without changing policies. Please provide the relevant entries from edge://policy, particularly proxy, IE integration/site-list, TLS, and extension policies. Were both tests performed on the same network/VPN, with the same account and browser version? That comparison will help distinguish management settings from network-path differences.
  3. Capture the failing request. In normal Edge, open F12 → Network, enable Preserve log, and reproduce once using dummy form data. Record the failed request’s hostname, method, status/error, protocol, and timing. This establishes whether the failing POST actually targets the main portal or another endpoint. Do not publicly upload unredacted HAR files, cookies, tokens, or submitted personal information.
  4. Verify the event source. Schannel events normally appear under Event Viewer → Windows Logs → System, with source Schannel, rather than the WebAuthN channel. Please paste the event ID, full message, and timestamp, and specify whether it came from the workstation or server. An event needs correlation with the failed request before attributing it to Edge.
  5. Check for TLS inspection. Compare the certificate issuer shown by the browser on managed and unmanaged machines. An enterprise/security-appliance issuer on only the managed machine would suggest an inspected connection; Microsoft documents this certificate check for its own TLS-inspection service. Ask the network team to correlate the failure timestamp with proxy/firewall and portal logs.
Working hypothesis—not a diagnosis: a management-related proxy, inspection component, or browsing-mode difference deserves investigation before OS cryptography changes. Your hybrid-key-exchange experiment is a useful clue, but because it did not stop the failures, it does not establish the cause.
Start by posting the full Edge versions, browsing mode, failed-request details, and exact event text. Leave certificate trust and TLS security settings unchanged while gathering that evidence.
 
Last edited:
You must log in or register to reply here.