MirthSync VS Code extension does not honor the Ignore Certificate Warnings setting

[mikeyw]

When connecting to my TEST Mirth server in VS Code, MirthSync is not honoring the Ignore Certificate Warnings global setting or the Development connection setting.

Each time I try to connect, I get the following error:

SSL certificate for https://SCH-MIRTHTEST01:8443 is invalid.

Clicking "Show Log" displays this:

MirthSync extension activating...
MirthSync extension activated successfully.
[2026-04-23T16:51:24.672Z] ERROR [connect]: [2001] unable to verify the first certificate
  Caused by: unable to verify the first certificate
[2026-04-23T17:52:04.388Z] ERROR [connect]: [2001] unable to verify the first certificate
  Caused by: unable to verify the first certificate

Please let me know if you need any additional information.

Thanks!

[mhokansonReliance]

I ran into this today and have the following findings to share:

Root cause analysis:

The extension's createHttpsAgent and MirthApiClient constructor correctly pass rejectUnauthorized: false from the connection profile to the axios httpsAgent. However, in practice the SSL error still occurs — likely because VS Code's extension host process doesn't reliably inherit user environment variables set via setx on Windows (e.g. NODE_TLS_REJECT_UNAUTHORIZED=0 set at the user level is not visible inside the extension host).

Workaround that confirms the fix:
Injecting process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0' at the top of the extension's activate() function (just before the "MirthSync extension activating..." log line) resolves the issue immediately.

Suggested fix in source:
At the start of the activate function, check the mirthsync.ignoreCertificateWarnings setting and set the env var programmatically:

const config = vscode.workspace.getConfiguration('mirthsync');
if (config.get('ignoreCertificateWarnings', false)) {
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';
}
This ensures the flag takes effect for the extension host process regardless of how VS Code was launched.

[jessesaga]

I think there's some confusion about that flag. There are actually 2 different connections to your server. The VSCode extension maintains an independent connection to pull relevant info about your mirth instance for the VSCode UI. Separately, when you run commands against your server, the plugin uses the mirthSync CLI tool with appropriate flags to perform the operations. The toggle that you see is relevant to the CLI invocation and not the VSCode connection. I'll look into ways to improve the UX around this. In the meantime, the way to deal with this issue is to create your server connections as "Development" connections and not "Production". The only difference between the 2 is around the certificate validation. <img width="634" height="336" alt="Image" src="https://github.com/user-attachments/assets/ec3226c3-629f-489b-b3e0-6850cd27e4ab" />

[mhokansonReliance]

I'm pretty sure all my connections were set up as "Development" connections when I was seeing the issue. Is there any way to check the Connection to confirm that?

[jessesaga]

Unfortunately the edit connection dialog allows you to edit everything but that setting currently. Your best bet would be to delete the connection and add another one.

Let me know if adding a new "development" connection does not fix the problem. It's possible there is some bug lurking here.

[mhokansonReliance]

I think that may have worked (remove and re-add).

Thanks!

[mikeyw]

Hi @jessesaga,

I have tried deleting and re-creating the connection, with both the hostname and the IP address, and am still getting the SSL error. Please let me know if I can provide any additional information.

SSL certificate for https://10.5.0.180:8443 could not be verified. Edit the connection and switch its SSL mode to "Development" to accept the certificate.

Thanks!

[jessesaga]

And you re-created them being sure to select "Development" rather than "Production" as the last step of the creation process? "Development" bypasses that cert check.

[mikeyw]

@jessesaga Correct. I selected Development, but it did not appear to bypass the cert check.

[jessesaga]

Thanks for the follow-up. With a development connection - the underlying http client flag should bypass this kind of cert error. A couple of things would help me narrow it down:

1. Could you run "MirthSync: Remove Connection" to delete every entry in the tree, then add a single fresh Development connection just to rule out a stale Production entry being tested?
2. Are you behind a corporate proxy or running endpoint security software that does SSL inspection (Zscaler, Netskope, Palo Alto GlobalProtect, certain AV products)? Those can sometimes inject a cert chain that fails to parse cleanly even when validation is disabled.
3. Could you try connecting from curl on the same machine - curl -kv https://10.5.0.180:8443/api/server/version - and share the TLS handshake output? If curl -k succeeds but the extension still fails, that'd point to a Node-specific parsing issue and I can dig further.

[mikeyw]

Hi @jessesaga ,

I think I might have found the issue. When I used the curl command you specified, the connection failed and the following error was returned:

curl -kv https://10.5.0.180:8443/api/server/version

HTTP ERROR 400 All requests must have 'X-Requested-With' header

I then added in the X-Requested-With header, and the connection succeeded.

curl -kv -H "X-Requested-With: XMLHttpRequest" https://10.5.0.180:8443/api/server/version

Have you seen this before? Would it be possible to add a config option to either send this header, or maybe just a field where a custom header can be entered?

Thanks!

[jessesaga]

We already send 'X-Requested-With' with every single request.

The curl command succeeds with the -k so we know your system is capable of talking to the mirth endpoint without TLS issues.

1. Could you confirm the extension version in the Extensions panel?
2. From a VS Code integrated terminal (not a separate terminal window), could you run the same curl plus an extra one:

   curl -kv -H "X-Requested-With: XMLHttpRequest" https://10.5.0.180:8443/api/server/version
   
   node -e "require('https').get({host:'10.5.0.180',port:8443,path:'/api/server/version',rejectUnauthorized:false,headers:{'X-Requested-With':'XMLHttpRequest'}},r=>{let d='';r.on('data',c=>d+=c);r.on('end',()=>console.log(r.statusCode,d))}).on('error',e=>console.error('ERR',e.code,e.message))"
   

   The first should give you the version. The second is essentially what the extension does. If Node can't connect but curl can, that would indicate a Node-specific TLS issue.
3. As a sanity check, could you try fully removing the extension (right-click - Uninstall, then reload), reinstalling, and creating a fresh Development connection? That'll rule out a stale stored profile from an older version.