-
Notifications
You must be signed in to change notification settings - Fork 257
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
Cloning to development container and extensions fail with self-signed SSL certificate #3713
Comments
Hi @KenxinKun, I may have found a solution to your first issue. I needed to add the following to {
"name": "myDevContainer",
// ...
"containerEnv": {
"NODE_EXTRA_CA_CERTS": "/etc/pki/tls/certs/ca-bundle.crt"
}
// ...
} The value is the file path that contains the bundle of MITM cert + the default certs. I had tried setting |
I have a similar kind of issue when building
|
@phillipcaofph I have the same issue. See: #5052 Downgrading the VS Code plugin worked for me. It seems related to Alpine switching to HTTPS for APK which is used by VS Code to bootstrap the volume before creating the Dev container. |
I've run into this as well - its very annoying |
Any luck on this for his second issue? |
Downgrading also worked for me. |
Was able to upgrade the extension lately but have to modify the extension's bootstrap Dockerfile. Modify the C:\Users<User>\AppData\Local\Temp\vsch\bootstrap-image<version>\bootstrap.Dockerfile file so that it looks like this: (Replace the zeroes with your certificate.
|
this limitation is really painfull for us. we would like a way to have a ready to use environment. maybe it would be an option to just download the devcontainer folder and use that instead of a bootstraping dockerfile when a devcontainer is in the repo. |
This workaround no longer works with version above 2.66. It seems that the dockerfile now downgrades to an old alpine ssh package. Does it meen I have to add the certificate elsewhere now ? |
For me it still works with Version 0.275.1 of the container-images. sometimes the inspect-volume is also used, then you have to add it also to those... |
we use crip to rip the public key from the certs and add them to the store. this works great in all dockerfiles which we can commit to the repo. BUT it's a real pain with this bootstrapping container which is not part of the repo and each dev needs hack around in this files to get this working. there should just be an easy (in a repo hostable) solution which applies automatically when a dev clones a volume. we would just need a way to auto-insert this into the bootstrap dockerfile
|
@OneCyrus Just an idea: can you maybe add this to the "base" image - mcr.microsoft.com/vscode/devcontainers/base:0-alpine-3.14 ? |
@resried that's not really a viable option as it doesn't scale to a dev org. for an individual dev this might be a workaround but we need something which is straight forward and just works without fragile hacks. |
I think the best option would be if there was a place/format to put the certs in your |
just to add a dirty tr
A dirty trick could be to add |
Then the following npm command will fail. |
ok then, maybe remove it, the npm command is for installing node-gyp and the npm might work with the usual env variables but the python part will not. |
I have found two issues when working with development containers that are related to self-signed SSL certificates:
When trying to install extensions through .devcontainer.json, this fails due to being behind a corporate firewall, that introduces self-signed certificates. Settings specified in the "non-containerised" VS Code to ignore SSL errors do not propagate down to the container created to install the extensions in the remote environment.
When trying to directly clone a repository into a container volume, since I am cloning from our own git servers, which also issue the same problematic self-signed certificate, the cloning fails. Note that since cloning fails, no settings can be retrieved from .devcontainer.json either, so the solution can't rely on that.
Workarounds found so far:
For the extensions, they manually install fine after container creation. In a separate issue it was specified that mounting additional volumes can make them persistent but it's not a fully automated solution. In my own containers I'm installing the self-signed certificate as a trusted CA too.
For the git cloning, I've manually modified the Dockerfile used by the extension located at
C:\Users\{username}\.vscode\extensions\ms-vscode-remote.remote-containers-0.140.1\scripts\volumeBootstrap.Dockerfile
and simply added an extra command at the endRUN git config --global http.sslVerify false
. This allowed the cloning to work without issue.It would be ideal if the extension would nicely propagate the settings around SSL down to the underlying.
Otherwise the extension is pretty amazing :)
The text was updated successfully, but these errors were encountered: