Launching Dev Container - Local workstation w/ corporate MITM SSL erroring

[spirilis]

• VSCode Version: 1.79.0-insiders
• Local OS Version: Windows 10
• Local chip architecture: x86_64
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: Multiple, but using Node.js w/ TypeScript for my examples

Steps to Reproduce:

This is an oddball scenario I hope nobody else has to deal with, but I have a feeling some do...

The likely cause of this is that my local workstation has a corporate-installed security tool called "Cisco Umbrella Client" which performs Man-in-the-Middle tunneling of all outbound TLS connections so that TLS traffic may be inspected inline by a security reporting tool. As a result, all TLS connections need to validate using the Cisco Umbrella root CA, which is installed on this workstation.

Remote-SSH to linux host with docker (toybox)

Start a new Dev Container - Node.js w/ TypeScript
Click "Show Log" before the dialog box disappears

Logs show:

[1280497 ms] Start: Run in Host: docker version --format {{.Server.APIVersion}}
[1280654 ms] 1.42
[1280655 ms] Start: Run in Host: docker pull alpine:3.16.3
[1281053 ms] Start: Run in Host: docker volume ls -q
[1287901 ms] Start: Run in Host: docker volume create --label dev.container.volume=true typescript-node-7
[1288054 ms] Start: Run in Host: docker run -d --mount type=volume,src=typescript-node-7,dst=/workspaces alpine:3.16.3 sleep infinity
[1288799 ms] Start: Run: C:\Users\ebrundic\AppData\Local\Programs\Microsoft VS Code Insiders\Code - Insiders.exe --ms-enable-electron-run-as-node c:\Users\ebrundic\.vscode-insiders\extensions\ms-vscode-remote.remote-containers-0.294.0\dist\spec-node\devContainersSpecCLI.js templates apply --workspace-folder C:\Users\ebrundic\AppData\Local\Temp\tmp-output-dir-1685713649262 --template-id ghcr.io/devcontainers/templates/typescript-node:latest --template-args {} --features [] --tmp-dir C:\Users\ebrundic\AppData\Local\Temp\tmp-dir-1685713649262
[1290895 ms] [2023-06-02T13:47:30.859Z] @devcontainers/cli 0.42.0. Node.js v16.17.1. win32 10.0.19044 x64.
[1290895 ms] Error: unable to get local issuer certificate
[1290896 ms]     at TLSSocket.onConnectSecure (node:_tls_wrap:1535:34)
[1290896 ms]     at TLSSocket.emit (node:events:513:28)
[1290896 ms]     at TLSSocket._finishInit (node:_tls_wrap:949:8)
[1290896 ms]     at ssl.onhandshakedone (node:_tls_wrap:730:12) {
[1290898 ms]   code: 'UNABLE_TO_GET_ISSUER_CERT_LOCALLY'
[1290900 ms] }
[1290901 ms] Start: Run in Host: docker rm -f f8b7fc64c9b48b05f51925cf19165a976bf1980e0e3bfdfd6405949a8e31cc1b

The VSCode node.js executor here (running local, using the devContainersSpecCLI.js running inside my Windows workstation, not on the remote host) does not seem to be honoring the local certificate store in this manner.

I do not have any specific logs to corroborate this but I'm guessing - that it's choking when reaching out to ghcr.io to read the "ghcr.io/devcontainers/templates/typescript-node:latest" manifest.

I've tried setting NODE_EXTRA_CA_CERTS to a copy of the Cisco Umbrella CA certificate but this made no difference, I still got UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

Is there any way to disable TLS certificate validation for the devContainersSpecCLI.js templates apply portion of this, or force it to use the local certificate store, or specify extra root CA's using an environment variable (like NODE_EXTRA_CA_CERTS)?

[bdsoha]

I'm having the exact same issue with a custom root CA and there is now way to set NODE_EXTRA_CA_CERTS.

I created a custom feature that installs the CA in the devcontainer, but unfortunately I cannot even get to that step due to the issue described above.

Error Output

[uncaught exception in sharedProcess]: 
unable to verify the first certificate:
Error: unable to verify the first certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1535:34)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket._finishInit (node:_tls_wrap:949:8)
    at ssl.onhandshakedone (node:_tls_wrap:730:12)

[pmierzwa]

I was able to solve it by going back to an old version of the dev containers extenstions. I havent pinpointed exactly which version did the trick but somewhere between 0.288.1 and 0.245.2 (where I confirmed the last one is working, and the first one is not).