[Bug]:Azure Managed Redis Entra ID login fails with "network_error": fetch failed behind TLS-inspecting proxy

Preconditions (Any important steps we need to know)

• Corporate environment with a TLS-inspecting forward proxy (Zscaler) that re-signs HTTPS traffic using an internal enterprise PKI (custom root/intermediate CA), not a publicly trusted CA.
• The internal root CA is installed and trusted in the Windows certificate store (browsers and other OS-integrated apps work fine).
• Attempting to connect to Azure Managed Redis using Microsoft Entra ID authentication.

Steps to reproduce (How to reproduce what you found step by step)

• Launch Redis Insight normally (via desktop/Start-menu shortcut) on a machine behind a TLS-inspecting proxy using an internal CA.
• Add a database / start the Azure Managed Redis connection flow using Entra ID authentication.
• Complete (or attempt) the Azure OAuth login (deeplink redirect).
• Observe the login fail with a generic error.

Actual behavior (A short description of what you found)

• Login fails with a generic "Azure authentication failed" message. Backend debug logs show the token exchange with Entra failing at the network layer:

INFO | AzureAuthController | Initiating Azure OAuth login with redirect type: deeplink
ERROR | AzureAuthService | Token acquisition failed: network_error: Network request failed: fetch failed

• Root cause: the Redis Insight Node backend uses only its bundled CA list for TLS validation and does not trust the OS/enterprise root store. When the proxy re-signs login.microsoftonline.com with the internal CA, Node rejects the certificate and the MSAL token request fails as a generic fetch failed. Inspecting the presented chain confirms it terminates at an internal enterprise root, e.g.:
  leaf: CN=stamp2.login.microsoftonline.com (issued by "Proxy")
  -> CN= Proxy (O=)
  -> CN= (DC=,...)
  -> CN= (self-signed internal root)

• Workaround: Export the internal CA chain to a PEM bundle and set NODE_EXTRA_CA_CERTS to that file before launching Redis Insight. After this, the backend trusts the inspected TLS and the Entra login succeeds. (Note: NODE_EXTRA_CA_CERTS only affects the Node backend, not the Chromium/Electron layer.)

Expected behavior (A short description of what you expected to find)

• The Node backend should trust the operating system / enterprise certificate store (or provide a documented, first-class setting) so Entra ID auth works out-of-the-box in TLS-inspecting corporate environments — consistent with browsers and other enterprise apps.
• On failure, the error should be actionable rather than a generic fetch failed / "Azure authentication failed" — e.g. surface the underlying TLS/certificate validation error (untrusted issuer, self-signed cert in chain) so users know it's a CA-trust problem.

Screenshots (Paste or drag-and-drop a screenshot or a link to a recording)

Additional context (Operating system, version of Redis Insight, Redis database version, Redis module version, database type, connection type, logs, or any other information)
OS: Windows 11 25H2
Redis Insight version: 3.8.0
Database type: Azure Managed Redis
Connection type / auth: Microsoft Entra ID (OAuth, deeplink redirect)
Proxy: Zscaler (TLS inspection enabled) using an internal enterprise PKI (custom root + intermediate CA); internal root trusted in Windows cert store
Relevant logs:

INFO | AzureAuthController | Initiating Azure OAuth login with redirect type: deeplink
ERROR | AzureAuthService | Token acquisition failed: network_error: Network request failed: fetch failed

• Additional observation: Chromium/Electron layer also logs handshake failed ... net_error -202 (ERR_CERT_AUTHORITY_INVALID) for some endpoints, which NODE_EXTRA_CA_CERTS does not address — suggesting the Electron network stack likewise does not consistently use the OS trust store.
• Workaround confirmed working: setting NODE_EXTRA_CA_CERTS to a PEM bundle containing the internal CA chain, then relaunching.

Start with AzureAuthController and AzureAuthService, then trace the Node backend token exchange and the Electron/Chromium network layer. Reproduce behind a TLS-inspecting proxy using the documented NODE_EXTRA_CA_CERTS workaround, and determine whether the completed behavior is successful Entra ID login or an actionable certificate-trust error.