"Allow insecure" option does not work

[code-asher]

For some reason, when we set this inside VS Code, it just does nothing. It works in tests so the code is correct, but maybe VS Code does some shenanigans with the http/s modules?

[code-asher]

I tried to reproduce and the insecure option now works for me. Maybe something was fixed upstream?

[code-asher]

I thought it could be related to the proxy support setting, but I have it set to override and it is still accepting my self-signed certificate with the insecure option enabled and rejecting it with that option disabled.

Issues like microsoft/vscode#173314 and my own examination of the code certainly seem to indicate that setting rejectUnauthorized should not work without disabling the proxy agent override, but here we are.

The http.proxyStrictSSL has no effect either.

[phorcys420]

(Discord thread)
We have an user in the Discord server that is encountering this problem even though the insecure option is toggled on.

Info

• VSCode channel: Stable
• VSCode version: waiting for an answer in the Discord thread
• OS: Windows
• Coder extension version: waiting for an answer in the Discord thread

Screenshots

Workaround

The problem seems to be fixed by setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to 0 OS/User-wide but that's not great.

[Marketos-Damigos]

(Discord thread) We have an user in the Discord server that is encountering this problem even though the insecure option is toggled on.

Info

• VSCode channel: Stable
• VSCode version: waiting for an answer in the Discord thread
• OS: Windows
• Coder extension version: waiting for an answer in the Discord thread

VS Code:

Version: 1.93.1 (user setup)
Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
Date: 2024-09-11T17:20:05.685Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

Coder extension version: 1.3.2

Nginx.conf:

events {
}


http {
    server {
        server_name example.tld;

        # HTTP configuration
        listen 80;

        # HTTP to HTTPS
        if ($scheme != "https") {
            return 301 https://$host$request_uri;
        }

        # HTTPS configuration
        listen 443 ssl;
        ssl_certificate /etc/nginx/certs/example.csr.crt;
        ssl_certificate_key /etc/nginx/certs/example.key;

        location / {
            proxy_pass  https://coder:3443; # Change this to your coder deployment port default is 3000
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection upgrade;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
            add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
        }
    }
}

[code-asher]

Does changing http.proxySupport to off or on have any effect?

[Marketos-Damigos]

Haven't tried it. I could try it and come back to you.

I event tried selecting the ca certs but this had no impact either.

[code-asher]

Please do! VS Code overrides our proxy agent (where we set rejectUnauthorized: false) when their proxy overrides ours, so it is possible this is causing the issue. But then again, maybe not, because I was not able to reproduce. 😢

As for the certificates, if you have access to it you might want to try the Coder: Tls Ca File option. I am not completely sure if VS Code handles certificates correctly, there could be a bug there.

[Marketos-Damigos]

I tried the coder: tls ca certificate but had no impact.

[Marketos-Damigos]

Does changing http.proxySupport to off or on have any effect?

This had no impact either

[code-asher]

Thank you for trying. It is strange, we set rejectUnauthorized: false but it seems like somewhere VS Code must be overriding that back to true. 🤔

[code-asher]

Or...maybe something to do with Axios?

[code-asher]

Did some more digging, I think rejectUnauthorized specifically only allows self-signed certificates. But "unable to verify the first certificate" implies there is a chain. Can you verify whether that is the case?

[code-asher]

One more comment: I am surprised the CA option did not work. Are you pointing it to the full chain or just part of it?

[Marketos-Damigos]

One more comment: I am surprised the CA option did not work. Are you pointing it to the full chain or just part of it?

I had a call with the person in my company that generates the certs. We went through it and used the whole bundle, unfortunately there was no difference. Is there a way to get more debugging or verbose for the extension when it tries to login?

[code-asher]

Sorry for the delayed response. "Unable to verify the first certificate" is all the debugging information we get from Node unfortunately, but Node does have an debug environment variable that might tell us more.

For example: NODE_DEBUG=tls code to launch VS Code with NODE_DEBUG set.

You may also want to try setting NODE_EXTRA_CA_CERTS pointed to your CA to see if that makes Node pick it up. There is definitely something wonky going on here but I am not sure what it is, I think I will need to set up some kind of reproduction but finding one is the tricky bit.

[Marketos-Damigos]

Thank you for the answer @code-asher . Will give them a try tomorrow and will get back to you

[Marketos-Damigos]

Unfortunately no luck with any of those. I set the node_debug as env variable for my user in windows but I couldn't get more logs during the error.

[code-asher]

Sorry about that, I should have tested it first. I guess NODE_DEBUG does not take effect for some reason but I am not sure why. Or maybe it does, but stdout is not getting logged anywhere.

I know you went through the certificate with someone already, but could you double-check by running this from the same machine VS Code is on? (You may have already ran something like this.)

openssl s_client -showcerts -connect <my domain>:443

You should see all the expected certs without any errors. Also, using something like https://www.ssllabs.com/ssltest/ to test the domain could be helpful, if it is public.

And you probably already tried this as well, but does curl <domain> work without any issues?

I hope to find some time to test your NGINX configuration with a self-signed certificate chain soon, there could very well be a bug in the plugin or some setting we are not configuring correctly.

I know this issue is actually about the insecure option not working though; I am still not sure why it seems to not be working in this case, but I will try to debug further if I am able to reproduce.