[Bug]: Installing extensions - unable to get issuer certificate

[ryjogo]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Remote Architecture: k8s
• code-server --version: 4.10.0

Steps to Reproduce

1. start code-server
2. code-server -vvv --auth none --port 13337 --install-extension ms-vscode.powershell

Expected

Should install the extensions using the ca's provided..

Actual

coder@workspaces-rgo-123:~$ export NODE_TLS_REJECT_UNAUTHORIZED=0
coder@workspaces-rgo-123:~$ export NODE_EXTRA_CA_CERTS=/home/coder/cert.pem
coder@workspaces-rgo-123:~$ code-server -vvv --auth none --port 13337 --install-extension ms-vscode.powershell 
[2023-03-03T09:45:20.909Z] debug Found VS Code arguments; spawning VS Code CLI
[2023-03-03T09:45:20.911Z] debug Running Code CLI
Installing extensions...
(node:30672) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
unable to get issuer certificate

Logs

No response

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

• I cannot reproduce this in VS Code.
• I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

• I am using HTTPS.

Notes

I have tried to use NODE_EXTRA_CA_CERTS but to no avail.

[code-asher]

VS Code unfortunately overrides NODE_TLS_REJECT_UNAUTHORIZED. Any idea if you get similar issues with curl? Just to rule out any Node or code-server issues. Maybe something like: ``` curl -L https://open-vsx.org/api/ms-vscode/powershell/2023.2.1/file/ms-vscode.powershell-2023.2.1.vsix -o ms-vscode.powershell-2023.2.1.vsix ```

[ryjogo]

Yes the curl request works fine, i get the file. I can also install the extension in the VSCode (web)UI.

[code-asher]

Oh that is very interesting. The UI just calls the code-server backend for installing extensions so if it works there it should work on the command line. Is there anything different about how you spawn the main code-server process compared to your shell? I assume you set NODE_EXTRA_CA_CERTS there as well?

[ryjogo]

So spawning the main code-server process is the standard:

/usr/bin/code-server --auth none --port 13337 >/tmp/code-server.log 2>&1 &

I am not setting NODE_EXTRA_CA_CERTS anywhere else actually, i set HTTP_PROXY, HTTPS_PROXY and NO_PROXY.

I am provisioning settings.json when the container boots:

  mkdir -p "/home/coder/.local/share/code-server/Machine"
  echo '{"http.proxyStrictSSL": false}' > /home/coder/.local/share/code-server/Machine/settings.json

My intention is however to install the extensions before spawning the main "daemon".

I have all the necessary certs in /etc/ssl/certs for our CA, and we are going through a corporate proxy with ssl interception, hence the need for CA's.

[ryjogo]

I just ran with NODE_DEBUG and i saw this:

this (masked) proxyserver.local is the proxy server address, so i can see it's connecting through this, however rejectUnauthorized is true?

... snip 1 million lines
NET 18505: createConnection [
  {
    host: 'proxyserver.local',
    port: 8080,
    auth: null,
    rejectUnauthorized: true
  },
  null,
  [Symbol(normalizedArgs)]: true
]
NET 18505: pipe false undefined
...

[code-asher]

Interesting! I tested echo '{"http.proxyStrictSSL": false}' > /home/coder/.local/share/code-server/Machine/settings.json and it appears to not take effect when installing from the command line but it does from the UI.

Putting it in User/settings.json does seem to work though. I am not sure why it seems to ignore Machine settings when running from the command line.

Still, even with rejectUnauthorized set to true it is strange that it struggles with the certificates.

[code-asher]

I am not sure how best to reproduce, I tried mitmproxy but I get a different error so this may not be one-to-one.

coder@dev:~$ rm ~/.local/share/code-server/extensions -r
coder@dev:~$ http_proxy=https://localhost:8000 code-server --install-extension ms-python.python
Installing extensions...
self signed certificate in certificate chain

Still, I suppose this can at least be used to test if NODE_EXTRA_CA_CERTS gets read and used.

coder@dev:~$ http_proxy=https://localhost:8000 NODE_EXTRA_CA_CERTS=$HOME/.mitmproxy/mitmproxy-ca.pem code-server --install-extension ms-python.python
Installing extensions...
Installing extension 'ms-python.python'...
Extension 'ms-python.python' v2023.4.0 was successfully installed.

Maybe there is something not quite right with your certificate? Although if it works for curl and friends I am not sure how that could be the case. 🤔

[code-asher]

One more thing, VS Code uses vscode-proxy-agent which is supposed to read certs from /etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-bundle.crt (in addition to whatever is in NODE_EXTRA_CA_CERTS). Controlled by the http.systemCertificates setting I believe. But adding certs to those paths does not actually seem to work in my testing, at least not from the command line.

https://github.com/microsoft/vscode-proxy-agent/blob/49c0f39c327ce408ce69247a3db10a2b313d44a2/src/index.ts#L454-L455

[ryjogo]

@code-asher Are you actually using the proxy there though?

i.e. are you sure that code-server is using the http url as you are only setting http_proxy, and not https_proxy too?

coder@dev:~$ http_proxy=https://localhost:8000 NODE_EXTRA_CA_CERTS=$HOME/.mitmproxy/mitmproxy-ca.pem code-server --install-extension ms-python.python
Installing extensions...

[ryjogo]

Thanks for the confirmation anyway.. it looks like there is some cert problem this side though, as it works there..

[code-asher]

are you sure that code-server is using the http url

Yeah, I see the requests in mitmproxy, plus if it was not using the proxy the run without the cert would not have failed. VS Code falls back to http_proxy even for https requests which does seem confusing (and on the flip side I believe it will use https_proxy for http requests if it is set).

Edit: Just to double-check I confirmed curl does it correctly so definitely seems like VS Code has an incorrect implementation.