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.
Preconditions (Any important steps we need to know)
Steps to reproduce (How to reproduce what you found step by step)
Actual behavior (A short description of what you found)
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)
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