Can't install extensions or use TLS/SSL behind corporate decrypting firewall without strictSSL=false

[brianary]

• VSCode Version: 1.3.1
• OS Version: Microsoft Windows 7 Professional 64-bit Service Pack 1 (6.1.7601)

Steps to Reproduce:

1. Search for extensions.
2. Click "Install".
3. The extension never switches from "Installing" to "Uninstall".

---

• VSCode Version: 1.4.0-insider
• Commit fc167f8
• Date 2016-07-26T05:09:25.359Z
• Shell 0.37.6
• Renderer 49.0.2623.75
• Node 5.10.0

Steps to Reproduce:

1. Search for extensions.
2. Click "Install".
3. "Error: self signed certificate in certificate chain"

---

We use a decrypting firewall, which requires adding a local cert as a trusted authority.

For some really dumb reason, both VS and VS Code do not seem to use the Windows list of Trusted Authorities, where the certs were placed by group policy. Right now we can choose just not to use any SSL content (all extensions tried so far), or disable all SSL checking (strict-ssl=false in user settings), which would be wildly irresponsible. So that's a huge hassle.

We really need either VS Code to honor imported Trusted Authorities from the Windows cert store, or a way to import a trusted cert into VS Code's special, unique snowflake cert store.

[joaomoreno]

@brianary I couldn't understand from your comment, but does setting "http.proxyStrictSSL": false in your settings work?

[brianary]

Yes, in the sense that I can install extensions without the benefit of a validated certificate chain, but that isn't really an option in a high-security environment.

[brianary]

This may be related to nodejs/node#3159

[joaomoreno]

Yeah it is, we are blocked by it.

One more question: did you need to also set up a proxy in Code?

[brianary]

No, we had a proxy at one time, but this current system operates on all network traffic through the firewall.

[joaomoreno]

And what happens is that firewall just patches the responses coming from the Internet with its own certificate?

[brianary]

The connection to the firewall is secured with its own cert, then a connection from the firewall to the destination uses the destination's cert. This allows the firewall to perform content filtering on https traffic.

[tracker1]

I'm having the same issue, but even with:

"http.proxyStrictSSL": false,

I'm getting the error, this change started with the 1.5.0 update that I just ran... Until this point it seemed to be content with the HTTP_PROXY environment setting... I always launch code from the terminal...

Even with configuring the http.proxy in code, I'm getting the error... I'm on an internal enterprise network, there is no access except via the proxy, the internal root cert is setup on the local machine iirc.

[brianary]

Same here with Insiders 1.5.0. It seems to be even more aggressively preventing local certs.

[darron-haworth]

I am experiencing the same thing. We do NOT have a proxy server and our corporate firewall decrypts all ssl traffic for inspection and then re-encrypts it using it's own intermediate cert. Our corporate intermediate cert is in my keychain (on mac) as a trusted certificate but VS Code does not recognize this trusted intermediate cert.

We have regretfully been working around this issue with "http.proxyStrictSSL": false in user settings but I just updated VS Code yesterday to Version 1.5.1 and now even the proxyStrictSSL=false is no longer working and I am continually getting "Error self signed certificate in certificate chain" even though the certificate is in my 'keychain', it is valid and issued by our corporate certificate authority.

It seems that something in the update to v1.5.1 has over-ridden the "http.proxyStrictSSL": false option. It would be nice if VS Code could honor the systems certificate trust settings!

[joaomoreno]

⚠️ For those who had this working before 1.5.0, here's the issue: #11702

[martinoss]

I also wish to be able to specify a ca in the settings like npm supports using "set ca". We're behind a TLS intercepting proxy. Setting proxyStrictSSL to false works but is not my preferred solution.

[gavinbeatty]

An alternative fix to using the system CA bundle is to do something similar to git's http.sslCAInfo option. Having something analogous to git -c http.sslCAInfo=/path/to/proxy.crt ... means users will always be able to fix the problem themselves -- using the system CAs is nice too, because the right bundle is often there, but that's not guaranteed either.

[MattAllison]

Same problem - our "proxy" is not a manually configured proxy server - it's an inline process handled by the firewall so the proxy setting options are not viable for us.

I'd prefer an option in the UI to import/trust the signing authority to having to find a way to download/distribute.

[joaomoreno]

Merging with #27838

[brianary]

This isn't a proxy issue. Why was this closed?

…

On Mon, Jul 3, 2017, 05:34 João Moreno ***@***.***> wrote: Closed #9790 <#9790>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9790 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH8mJ5fIlUF-9rIqaIYfSaDhk-PmS4GJks5sKN-6gaJpZM4JVQoG> .