-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Respect the OS certificate store #39
Comments
I'm having the same exact issue on my corporate device. We are behind the ZScaler proxy. Using the win-ca extension did not work as a workaround. |
Can confirm this issue is also present on Mac. To be more specific, it's only the language server that is not using it on Mac, the sidebar is working and showing workflow runs. |
Same behavior on Windows. At least it's consistent. |
Same here, Windows VSCode, the GitHub Copilot extension logs in fine after installing the win-ca, but this extension did not! |
Having the same issue on M1 MacOS Ventura.
|
I'm using a locally hosted reverse proxy to get past a hostname ban, not system proxy(which works fine) but the
|
Hey 👋. Can you confirm that the certificate you are using is in your Certificate Trust Chain? Here are the docs for troubleshooting this issue with Copilot. It might be the case that adding your self-signed certificate to the OS trust chain solves this problem for you. |
TL;DR Most extensions, including the sidebar of the Actions extension, are able to accept the certificate presented by the SSL-inspecting firewall, but the language server of the Actions extension does not. |
Took some time to investigate this issue. Was able to reproduce this locally by setting up Charles to act as a MITM SSL proxy for all GitHub API requests (requests made to The root cause of this is that we aren't reading in and passing root certificates to Node.js when making requests from within the extension. The Octokit REST API client (which we are using to make requests to the GitHub API) allows you to pass in an "agent" into requests. This looks something like this: const octokit = new Octokit({
request: {
agent: NodeHTTPSAgent
}
} We should creating a Node HTTPs agent and pass that into Octokit as the agent: import {Agent} from "node:https";
const httpsAgent = new Agent({
ca: selfSignedCerts
}); There are a few complications here as one of our goals is to make the language server work in the browser so we will need to polyfill any Node.js APIs. Other VSCode extensions have used win-ca and mac-ca to read in certificates from the OS's certificate store. For interacting with an OS's certificate store we will need OS-specific implementations as the APIs are different on Windows, Linux (Ubuntu) and MacOS. We are going to put this issue down for now but keep it open for future investigation/implementation. |
That's a shame. VSCode should really provide a common solution for other Node.js codebases. One thought is the side-bar part of this extension works, so whatever way it uses to make web requests is compatible. I presume that's because that part runs in VSCode instead of starting its own process? In which case, is it possible to run some code in VSCode as a proxy to handle web requests for the language server process? |
I have a workaround step to work.
$ export NODE_TLS_REJECT_UNAUTHORIZED="0"
$ code git-repo-directry I can now see some warning but the certificate error is gone in the extension log. |
In https://github.com/octokit/request.js/releases/tag/v7.0.0 node-fetch is removed. When this Octokit REST API client change trickles down here perhaps the implementation can start supporting the NODE_EXTRA_CA_CERTS environment variable - node-fetch doesn't. |
this issue still remains in 2024 |
|
Describe the bug
The "GitHub Actions language server" doesn't use Root certificates installed on Windows, so incompatible with an SSL-inspecting firewall.
Most other extensions in VSCode work just fine and are able to access HTTPS endpoints correctly. I presume they use a different API.
To Reproduce
Expected behavior
Certificates trusted by Windows are accepted.
Extension Version
v0.25.2
Additional context
I wonder if it's HSTS?
The text was updated successfully, but these errors were encountered: