VScode SSL self signed issue

[YFrendo]

Before submitting your bug report

• [X] I believe this is a bug. I'll try to join the Continue Discord for questions
• [X] I'm not able to find an open issue that reports the same bug
• [X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS:Ubuntu 22.04
- Continue:v0.9.156
- IDE:VSCode

Description

When verifySSL is false with a self Host api openapi like (vllm) there is still an error about the SSL verification.

To reproduce

1. Serve an API openai with self signed certificats
2. Configure the config.json with verifySsl: false and your URL
3. Use continue

Log output

Request to [myurl] failed, reason: unable to verify the first certificate

[jannikstdl]

Same issue here!

Related #889 #1423

[b333z]

I also hit this, had a quick look, and (maybe... but not my area) found something:

In https://github.com/continuedev/continue/blame/main/core/util/fetchWithOptions.ts

the agentOptions are setup:

  const agentOptions: {[key: string]: any} = {
    ca,
    rejectUnauthorized: requestOptions?.verifySsl,
    timeout,
    sessionTimeout: timeout,
    keepAlive: true,
    keepAliveMsecs: timeout,
  };

then the agentOptions are passed to one of 2 implementations depending on proxy/no-proxy:

  // Create agent
  const protocol = url.protocol === "https:" ? https : http;
  const agent =
    proxy && !requestOptions?.noProxy?.includes(url.hostname)
      ? protocol === https
        ? new HttpsProxyAgent(proxy, agentOptions)    // <- proxy
        : new HttpProxyAgent(proxy, agentOptions)
      : new protocol.Agent(agentOptions);                    // <- no-proxy

Don't these 2 implementations have different options requirements to disable cert verification (looks like the code currently only caters for the proxy path)

The proxy implementation HttpsProxyAgent(proxy, agentOptions) needs a rejectUnauthorized: false which agentOptions provides.

Doesn't this guy, the implementation selected in the no-proxy case: protocol.Agent(agentOptions) (which resolves to https.Agent(agentOptions)) require that you provide an alternate implementation of checkServerIdentity() that returns undefined to disable cert verification?

So something like this in it's agentOptions?:

checkServerIdentity: (servername: string, cert: any) => undefined

[frostronic]

Have there been any updates on this issue?

[b333z]

I think my previous comment was way off...

From what I've read, vscode overrides the http(s).Agent to provide proxy support which does not support passing through rejectUnauthorized: https://github.com/microsoft/vscode/issues/173314

Also seems like via the agent is the only way node-fetch allows passing rejectUnauthorized.

Workarounds: https://github.com/microsoft/vscode/issues/173314#issuecomment-1459899482 (setting Http: Proxy Support to off in vscode settings looks to work for me)

[donlinglok1]

in my case, i have a self sign cert but the domain name is not match to the URL. (xxx.com vs 192.168.x.x).

adding NODE_TLS_REJECT_UNAUTHORIZED=0 in system environment value works for me.

In windows: https://superuser.com/questions/949560/how-do-i-set-system-environment-variables-in-windows-10

[Xyz00777]

please provide support to ignore self signed certificates

[olkovi]

Yeah, it would help. Continue's good for when you need to run models on your own server, and this would be of much use for a service to be accessible from anywhere that's not the local network, without being forced to use http.

[beefster]

I finally found a workaround!

I manually pasted the URL of the blocked request in chrome, all I got was raw JSON error message but that doesn't matter - I was still able to inspect the certificate chain by clicking on the button to the left of the URL in the address bar, clicked 'connection is secure', clicked 'certificate is valid'. Then in the popup under the 'details' tab I found the intermediate certificate causing the problems (Zscaler in my case). Exported the individual certificate to a .crt file.

Then added the path to this file as NODE_EXTRA_CA_CERTS as an environment variable, at both the system and user level, probably only one is necessary.

Then, I installed the 'Node Extra CA Certs VSCode' extension, restarted my computer for good measure, and now continue.dev chat prompts are no longer getting blocked by this error. Uninstalled win-ca extension which apparently was doing nothing.

I had also screwed around with a bunch of proxy/cert related things in my VSCode settings, windows certificate store, and my environment variables trying to get this to work. I believe I reverted most of these and it didn't undo this fix, but if this fix doesn't work for anyone, I'll go back in and look around.

[deg0nz]

With the current version you can just set caBundlePath to your config and it should work: https://docs.continue.dev/reference/#requestoptions

[marcoce7]

Setting

  "models": [
    {
      "title": "Ollama",
      "provider": "ollama",
      "model": "AUTODETECT",
      "apiBase": "https://example.com:443"
      "requestOptions": {
        "caBundlePath": ["path-to-the-ca-certificate.pem"]
      }
    }

does not work for me. I get

[Extension Host] Error listing models:  Error: Error fetching tags: request to https://example.com/api/tags failed, reason: unable to get local issuer certificate

Also "verifySsl": false instead of the "caBundlePath" gives the same error.

The workaround in https://github.com/continuedev/continue/issues/1474#issuecomment-2669806066 works, but it would be great to be able to set this option in the configuration file instead of relying on environment variables and additional extensions.

Note that

curl --cacert path-to-the-ca-certificate.pem https://example.com:443/api/tags

works without problems.

[deg0nz]

@marcoce7 I'm currently not at my computer to verify this, but iirc the caBundlePath property is a string instead of a string array (which is present in your example).

[nopunYntendeed]

Wanted to try Continue with my local setup and I think I've also stumbled upon this issue. sslVerify nor caBundlePath worked for me. Notice the curl is made successfully

continue.continue Version 1.0.5 Last Updated 2025-04-05, 17:53:29

Godspeed

[mateusz91t]

Chat option works fine, but autocomplete raise an error for the same endpoint. :/

request to https://my-endpoint/openai/v1/completions failed, reason: unable to verify the first certificate

[griffin610]

Running into this issue as well trying to connect continue.dev to asksage. We're able to reach the api via the terminal and from the browser on our machines but are running into the unable to verify first certificate when continue attempts to call the API. We've tried the above solutions like installing win-ca and setting NODE_EXTRA_CA_CERTS along with installing the appropriate extension. Is there any other workaround to try? The CA bundle for the site is in our machines certificate manager.

[tblattner]

In extension.json (found in /.vscode/extensions/continue/out/extension.json)

I editted the async function "fetch2(url3, options_) to include

	// Add rejectUnauthorized: false to the options
    if (parsedURL.protocol === "https:") {
      options.rejectUnauthorized = false; // Disable SSL verification
    }

If someone could tell me how to pass this option into my config.yaml, that would be amazing. In the meantime everything is working now for me after passing that option.

I tried this in my yaml to no success:

    requestOptions:
      rejectUnauthorized: false  

(Note after modifying the file you have to restart vscode)

Here is a snippet of the fetch2 code from extension.json.

// ../../core/node_modules/node-fetch/src/index.js
async function fetch2(url3, options_) {
  return new Promise((resolve4, reject) => {
    const request4 = new Request2(url3, options_);
    const { parsedURL, options } = getNodeRequestOptions(request4);
    if (!supportedSchemas.has(parsedURL.protocol)) {
      throw new TypeError(`node-fetch cannot load ${url3}. URL scheme "${parsedURL.protocol.replace(/:$/, "")}" is not supported.`);
    }
    if (parsedURL.protocol === "data:") {
      const data2 = dist_default(request4.url);
      const response2 = new Response2(data2, { headers: { "Content-Type": data2.typeFull } });
      resolve4(response2);
      return;
    }
    const send = (parsedURL.protocol === "https:" ? import_node_https.default : import_node_http2.default).request;
    const { signal } = request4;
    let response = null;
    const abort2 = () => {
      const error = new AbortError("The operation was aborted.");
      reject(error);
      if (request4.body && request4.body instanceof import_node_stream2.default.Readable) {
        request4.body.destroy(error);
      }
      if (!response || !response.body) {
        return;
      }
      response.body.emit("error", error);
    };
    if (signal && signal.aborted) {
      abort2();
      return;
    }
    const abortAndFinalize = () => {
      abort2();
      finalize();
    };
	// Add rejectUnauthorized: false to the options
    if (parsedURL.protocol === "https:") {
      options.rejectUnauthorized = false; // Disable SSL verification
    }

Note, that I also tried adding this to my config.yaml with no luck:

requestOptions:
  verifySsl: false

[frolovgo]

requestOptions:
  verifySsl: false

works fine when i use "Default profile" in VS code. But when i select any custom profile - "self signed certificate in certificate chain"...

[github-actions[bot]]

This issue hasn't been updated in 90 days and will be closed after an additional 10 days without activity. If it's still important, please leave a comment and share any new information that would help us address the issue.

[github-actions[bot]]

This issue was closed because it wasn't updated for 10 days after being marked stale. If it's still important, please reopen + comment and we'll gladly take another look!

[perezjasonr]

Setting

  "models": [
    {
      "title": "Ollama",
      "provider": "ollama",
      "model": "AUTODETECT",
      "apiBase": "https://example.com:443"
      "requestOptions": {
        "caBundlePath": ["path-to-the-ca-certificate.pem"]
      }
    }

does not work for me. I get

[Extension Host] Error listing models:  Error: Error fetching tags: request to https://example.com/api/tags failed, reason: unable to get local issuer certificate

Also "verifySsl": false instead of the "caBundlePath" gives the same error.

The workaround in #1474 (comment) works, but it would be great to be able to set this option in the configuration file instead of relying on environment variables and additional extensions.

Note that

curl --cacert path-to-the-ca-certificate.pem https://example.com:443/api/tags

works without problems.

Otherwise, you can look at using requestOptions (verifySsl = false, or caBundlePath): https://docs.continue.dev/reference#models

im getting this error on the cn cli using aws and bedrock, even if i use verifySsl = false, or caBundlePath aws cli is able to do calls successfully using similar args ie ca_bundle = xyz or the ENV VAR equivalent