Remote container - "self signed certificate in certificate chain" for /api/graphql even if "ignore certificate errors" is checked

Summary

edit 20210625 : This wasn't happening before. The problem appeared from version 3.11.2 and onward.

When using gitlab workflow in a VScode remote container and our self-hosted gitlab instance (13.8), I get "self signed certificate in certificate chain" for /api/graphql endpoint even if I checked "ignore certificate errors".

This doesn't happen when not using remote container (ie.: vscode on my machine directly).

Steps to reproduce

  1. Clone project from self-hosted, self-signed gitlab instance into a container, open with vscode remote container extension.

  2. Install Gitlab workflow (remote)

  3. Check "ignore certificate errors" in settings

What is the current bug behavior?

Gitlab workflow can't load project:

Status in the bottom bar are all in "fetching" state: image

Sidebar: image

What is the expected correct behavior?

Gitlab workflow successfully loads the info from Gitlab selfhosted instance:

image

image

Relevant logs and/or screenshots

From the Gitlab Workflow "output" tab:

request to https://abe.......net/api/graphql failed, reason: self signed certificate in certificate chain
FetchError: request to https://abe.......net/api/graphql failed, reason: self signed certificate in certificate chain
	at ClientRequest.<anonymous> (/root/.vscode-server/extensions/gitlab.gitlab-workflow-3.20.1/node_modules/node-fetch/lib/index.js:1461:11)
	at ClientRequest.emit (events.js:315:20)
	at TLSSocket.socketErrorListener (_http_client.js:469:9)
	at TLSSocket.emit (events.js:315:20)
	at emitErrorNT (internal/streams/destroy.js:106:8)
	at emitErrorCloseNT (internal/streams/destroy.js:74:3)
	at processTicksAndRejections (internal/process/task_queues.js:80:21)

Possible fixes

Seems like it could be related to : #314 (closed), but I don't have http.proxy setting set (although I'm behind a proxy).

Edited by Dge gag