Feature req: Self signed certs / corporate proxy certs local

[PDXPuma]

One of the big blockers for me and my org regarding devcontainer adoption is around company based certs built around traffic inspection.

(Think Zscaler, etc, others that use a wildcard cert in the middle to inspect traffic to sites)

A potential fix for this would be a feature that allowed one to point to a file in the devcontainer directory, and that file could be injected/updated etc, for as many means as possible.

Feature options could include whether or not to add it to the NODE env variables to pick it up, adding it to the system certificate store, adding it to java stores, or adding it to various places with custom commands as needed by the various cert stores that get used in dev environments.

This would allow us to incorporate devcontainers faster in onboarding as we could locate the crts outside the repos and reference them from inside the devcontainers.

[Kaniska244]

Hello @PDXPuma ,

Thank you for this new feature request. Would you kindly elaborate further on the below points for this?

• What would be the format(.pem, .crt, .der, .cer, .pfx, .p12 etc) of the input certificates & how would they be given to the feature as input?

• Would you kindly elaborate further on adding it to various places with custom commands as needed by the various cert stores that get used in dev environments and specify the exact requirement in this regard?

• When it comes to adding certificates to NODE env variables, do you mean adding the certificates to NODE env variable NODE_EXTRA_CA_CERTS. Also while adding the certificates to this variable, multiple certificates content have to be copied into a .pem file. Would such a .pem file be also given in the input or is it expected to be converted as part of the feature from other format provided in the input?

• While adding the certs in java store, would the file be provided in .jks format or is it expected to be converted as part of the feature from other format provided in the input?

[PDXPuma]

Certainly. In our case, what we're doing is adding in the crts as part of the devcontainer directory as crts. .pem files I am certain would work

What I currently do for work is use a docker file to copy the container into the proper places, and then add the appropriate update-certtificates for the given docker container. My expectation would be that the feature add it to the system store, and then in the cases of java/jvms , add it to any of those appropriate stores with the java keytool:

keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias yourAliasName -file path\to\certificate.crt

The node env variables are correct, the NODE_EXTRA_CA_CERTS. I think for a first run/test it might be within the scope to require the user to supply this premade into a pem file. For future versions of the feature I can imagine the feature itself as part of the container setting things up, but I also realize that expands the scope of testing significantly.

I think that answer goes for everything in the first few revs of this feature, that it would be acceptable to have the user supply locations local and remote to the necessary files without any conversion.