Use local SSL trust store #1159

Open
opened 2026-02-16 17:29:49 -05:00 by yindo · 11 comments
Owner

Originally created by @Clete2 on GitHub (Aug 7, 2025).

Originally assigned to: @thdxr on GitHub.

I am using opencode with a LiteLLM proxy that has a SSL cert signed internally by my corporate organization.

When I try to test it, I get an error message: "UnknownError Error: unable to get local issuer certificate"

Image

When I cURL the LiteLLM proxy URL, it works, because the certificate is signed by a trusted signer. Opencode should use my system truststore.

macOS Sequoia 15.6

(PS I also am having #1154 as an issue, which might be related, I am not sure)

Originally created by @Clete2 on GitHub (Aug 7, 2025). Originally assigned to: @thdxr on GitHub. I am using opencode with a LiteLLM proxy that has a SSL cert signed internally by my corporate organization. When I try to test it, I get an error message: "UnknownError Error: unable to get local issuer certificate" <img width="1392" height="791" alt="Image" src="https://github.com/user-attachments/assets/0daae438-de2d-4a7c-9175-0976e5f313fd" /> When I cURL the LiteLLM proxy URL, it works, because the certificate is signed by a trusted signer. Opencode should use my system truststore. macOS Sequoia 15.6 (PS I also am having #1154 as an issue, which might be related, I am not sure)
yindo added the help-wanted label 2026-02-16 17:29:49 -05:00
Author
Owner

@Clete2 commented on GitHub (Aug 8, 2025):

For now I can work around it with "NODE_TLS_REJECT_UNAUTHORIZED=0"

@Clete2 commented on GitHub (Aug 8, 2025): For now I can work around it with "NODE_TLS_REJECT_UNAUTHORIZED=0"
Author
Owner

@thdxr commented on GitHub (Aug 11, 2025):

does setting NODE_EXTRA_CA_CERTS fix?

@thdxr commented on GitHub (Aug 11, 2025): does setting NODE_EXTRA_CA_CERTS fix?
Author
Owner

@Clete2 commented on GitHub (Aug 12, 2025):

@thdxr yes, but most apps just use system store without having to specify.

~> opencode # error
~> NODE_EXTRA_CA_CERTS=truststore.crt opencode # works

I'm not familiar with what HTTP libraries are being used, but maybe there's one that can use system certs?

For instance, when using npm, I connect to a custom package proxy URL which has a company-signed SSL cert, and I don't have any special configuration that I know of which makes it trust that cert.

Setup is like... Mac -> Zscaler -> GitHub Copilot. SSL decrypt enabled, so the destination appears to have a company-signed certifiate.

@Clete2 commented on GitHub (Aug 12, 2025): @thdxr yes, but most apps just use system store without having to specify. ``` ~> opencode # error ~> NODE_EXTRA_CA_CERTS=truststore.crt opencode # works ``` I'm not familiar with what HTTP libraries are being used, but maybe there's one that can use system certs? For instance, when using npm, I connect to a custom package proxy URL which has a company-signed SSL cert, and I don't have any special configuration that I know of which makes it trust that cert. Setup is like... Mac -> Zscaler -> GitHub Copilot. SSL decrypt enabled, so the destination appears to have a company-signed certifiate.
Author
Owner

@thdxr commented on GitHub (Aug 12, 2025):

this isn't something bun or node seems to do automatically. need to see if we can load it somehow

@thdxr commented on GitHub (Aug 12, 2025): this isn't something bun or node seems to do automatically. need to see if we can load it somehow
Author
Owner

@james-gour commented on GitHub (Oct 24, 2025):

I am also getting this! This will need to be fixed for many corporate settings :)

@james-gour commented on GitHub (Oct 24, 2025): I am also getting this! This will need to be fixed for many corporate settings :)
Author
Owner

@maxious commented on GitHub (Dec 23, 2025):

NODE_OPTIONS="--use-system-ca" or BUN_OPTIONS="--use-system-ca" should allow use of local corporate proxy certificates stored in the system security store. https://nodejs.org/docs/v23.8.0/api/cli.html#--use-system-ca

This option was added to node in v22/23 this year which sadly means some LLMs with 2024 knowledge still think it's impossible 😂

@maxious commented on GitHub (Dec 23, 2025): NODE_OPTIONS="--use-system-ca" or BUN_OPTIONS="--use-system-ca" should allow use of local corporate proxy certificates stored in the system security store. https://nodejs.org/docs/v23.8.0/api/cli.html#--use-system-ca This option was added to [node in v22/23 this year](https://github.com/nodejs/node/pull/56833) which sadly means some LLMs with 2024 knowledge still think it's impossible 😂
Author
Owner

@davidw-philips commented on GitHub (Jan 5, 2026):

Same issue here, deep wiki failing over http due to corporate proxy,, can't set in ENV variables without allowing insecure TLS.

@davidw-philips commented on GitHub (Jan 5, 2026): Same issue here, deep wiki failing over http due to corporate proxy,, can't set in ENV variables without allowing insecure TLS.
Author
Owner

@amolmishra23 commented on GitHub (Jan 17, 2026):

Facing the same issue. FYI I am running with the currently available latest version.

~ ❯ opencode --version                                                                                                                                                                                                                                                       
1.1.25

Also tried using the NODE_OPTIONS="--use-system-ca" or BUN_OPTIONS="--use-system-ca". Doesnt work either. On same 1.1.25 version.

The only option which so far worked for me is, NODE_TLS_REJECT_UNAUTHORIZED=0.

Why cant we have a permanent fix for this? Given everything else works perfectly in my corporate proxy (Cursor, VS Code, Antigravity etc).

@amolmishra23 commented on GitHub (Jan 17, 2026): Facing the same issue. FYI I am running with the currently available latest version. ```bash ~ ❯ opencode --version 1.1.25 ``` Also tried using the NODE_OPTIONS="--use-system-ca" or BUN_OPTIONS="--use-system-ca". Doesnt work either. On same 1.1.25 version. The only option which so far worked for me is, NODE_TLS_REJECT_UNAUTHORIZED=0. Why cant we have a permanent fix for this? Given everything else works perfectly in my corporate proxy (Cursor, VS Code, Antigravity etc).
Author
Owner

@yancgi commented on GitHub (Jan 22, 2026):

On Linux, I resolved this adding this env variable in my .bashrc file:

export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt

Note: the file ca-certificates.crt does include our company's ZScaler root certificate.

@yancgi commented on GitHub (Jan 22, 2026): On Linux, I resolved this adding this env variable in my `.bashrc` file: ``` export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt ``` **Note:** the file `ca-certificates.crt` does include our company's ZScaler root certificate.
Author
Owner

@dklymenk commented on GitHub (Jan 23, 2026):

I found a workaround for my exact case, using github-copilot provider. Copilot is an approved LLM provider in my org, but opencode fails to interact with it.

My employer takes it a step further with their Zscaler setup. Even when I manage to get past the "Error: unable to get local issuer certificate", opencode just gets stuck with a loading animation. Meanwhile, the proprietary github copilot cli and the vscode extension were totally fine.

https://models.dev/api.json lists https://api.githubcopilot.com/ as the API URL for github-copilot. This host doesn't just get its certificate replaced by Zscaler, it actually redirects you to some "safe browsing" environment. Needless to say, no POST request bodies survive that. The host is essentially banned for API use.

By looking through Zscaler logs, I found that github copilot cli is instead calling https://api.business.githubcopilot.com/, which doesn't even have any man-in-the-middle business -- I see the original GitHub certificate. I assume copilot CLI is looking into whether my copilot plan is coming from my org and uses the business url for API requests.

After that, getting past Zscaler was only a matter of updating ~/.cache/opencode/models.json with the whitelisted URL and starting opencode with OPENCODE_DISABLE_MODELS_FETCH=true opencode.

Currently, I'm using an alias that replaces the URL and starts opencode with the env var:

alias oc="sed -i '' 's/api\.githubcopilot\.com/api.business.githubcopilot.com/g' ~/.cache/opencode/models.json && OPENCODE_DISABLE_MODELS_FETCH=true opencode"

When a new model is released, I plan to run opencode to refetch the models, close it and get back to oc.

@dklymenk commented on GitHub (Jan 23, 2026): I found a workaround for my exact case, using github-copilot provider. Copilot is an approved LLM provider in my org, but opencode fails to interact with it. My employer takes it a step further with their Zscaler setup. Even when I manage to get past the "Error: unable to get local issuer certificate", opencode just gets stuck with a loading animation. Meanwhile, the proprietary github copilot cli and the vscode extension were totally fine. https://models.dev/api.json lists https://api.githubcopilot.com/ as the API URL for github-copilot. This host doesn't just get its certificate replaced by Zscaler, it actually redirects you to some "safe browsing" environment. Needless to say, no POST request bodies survive that. The host is essentially banned for API use. By looking through Zscaler logs, I found that github copilot cli is instead calling https://api.business.githubcopilot.com/, which doesn't even have any man-in-the-middle business -- I see the original GitHub certificate. I assume copilot CLI is looking into whether my copilot plan is coming from my org and uses the business url for API requests. After that, getting past Zscaler was only a matter of updating `~/.cache/opencode/models.json` with the whitelisted URL and starting opencode with `OPENCODE_DISABLE_MODELS_FETCH=true opencode`. Currently, I'm using an alias that replaces the URL and starts opencode with the env var: ```sh alias oc="sed -i '' 's/api\.githubcopilot\.com/api.business.githubcopilot.com/g' ~/.cache/opencode/models.json && OPENCODE_DISABLE_MODELS_FETCH=true opencode" ``` When a new model is released, I plan to run `opencode` to refetch the models, close it and get back to `oc`.
Author
Owner

@dklymenk commented on GitHub (Jan 23, 2026):

I also wanted to do a summary of the "Error: unable to get local issuer certificate" solutions above:

  • NODE_TLS_REJECT_UNAUTHORIZED=0 works but exposes you to potential MITM attacks if someone were to sit between you and Zscaler. This also blindly disables SSL certificate verification for all requests bun/opencode would make (even ones not going through zscaler) exposing you even more.
  • NODE_EXTRA_CA_CERTS works if you don't mind going through the trouble of exporting the certificate from your keychain and converting the binary into the plain text PEM thing that bun/node expect.
  • NODE_OPTIONS="--use-system-ca" has no effect, likely not supported by bun at all
  • BUN_OPTIONS="--use-system-ca" prevents opencode from opening at all, likely related to https://github.com/oven-sh/bun/issues/20347. BUN_OPTIONS seems to break bun parameter parsing.

There is a way to use --use-system-ca, if you were to clone opencode and add it directly to the dev script in package.json. However, for most users, I would assume exporting the certificate and passing it via NODE_EXTRA_CA_CERTS is the cleanest and the safest solution.

@dklymenk commented on GitHub (Jan 23, 2026): I also wanted to do a summary of the "Error: unable to get local issuer certificate" solutions above: * `NODE_TLS_REJECT_UNAUTHORIZED=0` works but exposes you to potential MITM attacks if someone were to sit between you and Zscaler. This also blindly disables SSL certificate verification for all requests bun/opencode would make (even ones not going through zscaler) exposing you even more. * `NODE_EXTRA_CA_CERTS` works if you don't mind going through the trouble of exporting the certificate from your keychain and converting the binary into the plain text PEM thing that bun/node expect. * `NODE_OPTIONS="--use-system-ca"` has no effect, likely not supported by bun at all * `BUN_OPTIONS="--use-system-ca"` prevents opencode from opening at all, likely related to https://github.com/oven-sh/bun/issues/20347. BUN_OPTIONS seems to break bun parameter parsing. There is a way to use `--use-system-ca`, if you were to clone opencode and add it directly to the `dev` script in [package.json](https://github.com/anomalyco/opencode/blob/dev/package.json#L9). However, for most users, I would assume exporting the certificate and passing it via `NODE_EXTRA_CA_CERTS` is the cleanest and the safest solution.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1159