NodeRequestor fails in electron in the presence of self-signed certificates (e.g. corporate machines/networks)

[MichaelBelousov]

I have a user who is getting an error self signed certificate in certificate chain error when trying to login from their corporate machine.

My suspicion is that when you use the openid node requestor on this line, it fails there as the default fetch and http/https packages in electron do not support using the user's certificate store. Electron's (new) electron.net.fetch function however does use those certificates.

As such, I have the following main/Client.js patch I'm using locally to workaround this.
Note that for brevity I have neglected to show the parts of the patch replacing other node_requestor usages, but those should be replaced too.

+
+
+/// START ELECTRON REQUESTOR PATCH IMPL
+const { AppAuthError } = require('@openid/appauth/built/errors.js');
+const { log } = require('@openid/appauth/built/logger.js');
+const { Requestor } = require('@openid/appauth/built/xhr.js');
+
+/** @type {import("electron").net.fetch} */
+const fetch = require('electron').net.fetch;
+
+/**
+ * An electron.net.fetch HTTP client (to support user certificates)
+ */
+class ElectronRequestor extends Requestor {
+  /**
+   * @template T
+   * @param {JQueryAjaxSettings} settings
+   * @returns {Promise<T>} settings
+   */
+  async xhr(settings) {
+    // implementing a subset that is required.
+
+    /** @type {Response} */
+    let resp;
+    try {
+      resp = await fetch(
+        settings.url,
+        {
+          method: settings.data ? "POST" : undefined,
+          headers: {
+            ...settings.headers,
+            // THIS seems to cause electron's use of chromium's fetch to return Uncaught Error: net::ERR_INVALID_ARGUMENT
+            // so just let it do it automatically
+            //...settings.data && {
+              //'Content-Length': String(settings.data.toString().length),
+            //},
+          },
+          body: settings.data,
+        },
+      );
+    } catch (err) {
+      log('Request throw an error ', err); 
+      console.error("REQUEST ERROR", err)
+      throw err;
+    }
+
+    if (resp.status !== 200) {
+      log('Request ended with an error ', resp.status); 
+      throw new AppAuthError(resp.statusText);
+    }
+
+    if (settings.dataType === "json") {
+      // NOTE: NodeRequestor implementation logged JSON parse errors here
+      return resp.json();
+    } else {
+      return resp.text();
+    }
+  }
+}
+/// END ELECTRON REQUESTOR PATCH IMPL
+
 /**
  * Utility to generate OIDC/OAuth tokens for Desktop Applications
  * @beta
@@ -167,7 +229,7 @@ class ElectronMainAuthorization {
      */
     async signIn() {
         if (!this._configuration) {
-            const tokenRequestor = new node_support_1.NodeRequestor(); // the Node.js based HTTP client
+            const tokenRequestor = new ElectronRequestor();
             this._configuration =
                 await appauth_1.AuthorizationServiceConfiguration.fetchFromIssuer(this._issuerUrl, tokenRequestor);
             core_bentley_1.Logger.logTrace(loggerCategory, "Initialized service configuration", () => ({ configuration: this._configuration }));
@@ -186,11 +248,13 @@ class ElectronMainAuthorization {

I will reply if there were any issues after my user tests it. I just don't want to forget about it so I am already posting it as a known issue.

More information on electron.net.fetch issues here
electron/electron#45674

[MichaelBelousov]

I suppose one issue to note is, it seems any electron app (that wants to work on a classic corporate IT setup) may have to purge all of its dependencies of usage of the https/http modules, and patch globalThis.fetch to be electron.net.fetch.

the alternatives are:

• disable TLS for some certificate validation attempts (bad idea but what people seem to (used to) do for electron)
• use electron.net.fetch everywhere since it will trust validated local self-signed certificates (need to patch everything as I said)
• find the certificate on the machine yourself (or have a user configure it) and build your own global undici.Agent which is aware of that certificate. You may still need to patch some usages of import('node:http'), I'm not sure.
• maybe run your own certificate validation in a certificate-error event handler in electron

[ben-polinsky]

Yeah this is a PITA. I've used electron.net in the past and am in favor of that solution.

Thanks for bringing this to our attention, Mike.

[aruniverse]

cc @alexdunae

[alexdunae]

We ended up polyfilling all the Node networking code (https, tls) using @vscode/proxy-agent in the same way that VS Code does. It seems to be working well.

If you have networking calls using libcurl like they do in imodeljs-native those are still not working with the user's system certificate store but that is being addressed currently.

[alexdunae]

When Node 24 comes there is also a new --use-system-ca CLI flag that should make these polyfills unnecessary.

[MichaelBelousov]

We ended up polyfilling all the Node networking code (https, tls) using [@vscode/proxy-agent)(https://github.com/microsoft/vscode-proxy-agent) in the same way that VS Code does. It seems to be working well.

Thank you. I'll run with that explanation.

Would be nice if this were documented in the desktop template or even incorporated into it, but perhaps closing this issue and referring to it is enough.

[MichaelBelousov]

for posterity, it certainly would be nice if you had a code snippet @alexdunae

[alexdunae]

@MichaelBelousov here's an extract...

let isPolyfilled = false;

/** By default, Node uses it's built-in store of trusted certificates for all networking requests.
 * This can cause problems in corporate networks where the corporate proxy uses self-signed certificates or
 * other certificates with untrusted roots.
 *
 * To work around this we use the @vscode/proxy-agent package to load the user's trusted certificates from their operating
 * system and polyfill various networking functions to trust those certificates.  We also use `electron.net.fetch` whenever
 * possible, since it already uses the system's trusted certificates.
 *
 * This approach was inspired by VS Code's networking code:
 * https://github.com/microsoft/vscode/blob/e5529dcf7c64d1fbd589da15efa8dea444172236/src/vs/workbench/api/node/proxyResolver.ts#L117-L177
 *
 * Node 23+ introduced the `--use-system-ca` flag which will hopefully eliminate the need for this code in the future.
 */
export function polyfillNetworking(context: PolyfillContext) {
  if (isPolyfilled) return;
  polyfillFetch(context);
  polyfillNetworkingModules(context);
  isPolyfilled = true;
}

/** Polyfill Node's built-in fetch function.
 *
 * `node-fetch` uses `https.request` under the hood, so it gets patched when we polyfill `https.request` later on.
 */
function polyfillFetch(context: PolyfillContext) {
  const patchedFetch = proxyAgent.createFetchPatch(proxyAgentParams, globalThis.fetch, proxyAgentParams.resolveProxy);
  LoggingService.logTrace(`${LOG_TAG} patchGlobalFetch context=${context}`);

  globalThis.fetch = async function fetch(input: string | URL | Request, init?: RequestInit) {
    function getRequestProperty(name: keyof Request & keyof RequestInit) {
      if (init && name in init) {
        return init[name];
      }
      if (typeof input === "object" && "cache" in input) {
        return input[name];
      }

      return undefined;
    }

    // Limitations: https://github.com/electron/electron/pull/36733#issuecomment-1405615494
    // net.fetch fails on manual redirect: https://github.com/electron/electron/issues/43715
    const urlString = typeof input === "string" ? input : "cache" in input ? input.url : input.toString();
    const unsupportedByElectronNetFetch =
      urlString.startsWith("data:") ||
      urlString.startsWith("blob:") ||
      getRequestProperty("redirect") === "manual" ||
      getRequestProperty("integrity");

    // net.fetch does not support blob:, data:, `redirect: manual`, or Request(url, { integrity: "sha256-..." })
    // so we use the patched fetch from @vscode/proxy-agent instead
    // https://github.com/electron/electron/pull/36733#issuecomment-1405615494
    if (unsupportedByElectronNetFetch) {
      LoggingService.logTrace(
        `${LOG_TAG} unsupportedByElectronNetFetch: using patchedFetch instead of Electron fetch`,
        init
      );
      return await patchedFetch(input, init);
    }

    if (init?.headers) {
      const headers = new Headers(init.headers);
      for (const header of UNSAFE_FETCH_HEADERS) {
        headers.delete(header);
      }
      init = { ...init, headers };
    }

    // work around outdated types: https://github.com/electron/electron/issues/43712
    const electronInput = input instanceof URL ? input.toString() : input;
    LoggingService.logTrace(`${LOG_TAG} using electron.net.fetch`, init);
    return await electron.net.fetch(electronInput, init);
  };
}

/** Polyfill the tls, net, http and https modules */
function polyfillNetworkingModules(context: PolyfillContext) {
  LoggingService.logTrace(`${LOG_TAG} content=${context} patchNetworkingModules`);

  const tlsPatch = proxyAgent.createTlsPatch(proxyAgentParams, tls);
  tls.connect = tlsPatch.connect;
  tls.createSecureContext = tlsPatch.createSecureContext;

  const netPatch = proxyAgent.createNetPatch(proxyAgentParams, net);
  net.connect = netPatch.connect;

  const httpsPatch = proxyAgent.createHttpPatch(proxyAgentParams, https, resolveProxyWithRequest);
  https.get = httpsPatch.get as any;
  https.request = httpsPatch.request as any;

  const httpPatch = proxyAgent.createHttpPatch(proxyAgentParams, http, resolveProxyWithRequest);
  http.get = httpPatch.get as any;
  http.request = httpPatch.request as any;
}

// Unsupported headers: https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/header_util.cc;l=32;drc=ee7299f8961a1b05a3554efcc496b6daa0d7f6e1
const UNSAFE_FETCH_HEADERS = [
  "content-length",
  "cookie2",
  "host",
  "keep-alive",
  "set-cookie",
  "te",
  "trailer",
  "transfer-encoding",
  "upgrade",
];

const proxyAgentLogger: proxyAgent.Log = {
  trace: (message: string) => LoggingService.logTrace(`${LOG_TAG}: ${message}`),
  debug: (message: string) => LoggingService.logTrace(`${LOG_TAG}: ${message}`),
  info: (message: string) => LoggingService.logInfo(`${LOG_TAG}: ${message}`),
  warn: (message: string) => LoggingService.logWarning(`${LOG_TAG}: ${message}`),
  error: (message: string) => LoggingService.logError(`${LOG_TAG}: ${message}`),
};

// no proxy, just connect directly
const resolveProxyWithRequest: proxyAgent.ResolveProxyWithRequest = (
  _flags,
  _request: http.ClientRequest,
  _opts: http.RequestOptions,
  _url: string,
  callback: (proxy?: string) => void
) => callback("DIRECT");

// we only want to use @vscode/proxy-agent's additional certificate loading, not the proxying,
// so we set all these config settings to skip proxying
export const proxyAgentParams: proxyAgent.ProxyAgentParams = {
  resolveProxy: async (_url: string) => "DIRECT",
  getProxyURL: () => undefined,
  getProxySupport: () => "off",
  isUseHostProxyEnabled: () => false,
  proxyResolveTelemetry() {},

  env: process.env,
  log: proxyAgentLogger,
  getLogLevel: () => proxyAgent.LogLevel.Trace,

  // must be set to true otherwise proxy-agent will not create a patched version of `fetch``
  isAdditionalFetchSupportEnabled: () => true,

  // add all system certificates to the patched versions of the networking functions
  addCertificatesV1: () => true,
  addCertificatesV2: () => true,
  loadAdditionalCertificates: async () => {
    return proxyAgent.loadSystemCertificates({ log: proxyAgentLogger });
  },
};

[ben-polinsky]

When Node 24 comes there is also a new --use-system-ca CLI flag that should make these polyfills unnecessary.

Oh happy day! Congratulations all around.