Windows Client Fails to Connect to Sync Server over HTTPS with Self-Signed Certificate

[arizuka]

Description

I have set up a TriliumNext sync server on a Raspberry Pi at 192.168.88.24:65443, configured to use HTTPS with a self-signed certificate. On my Windows 10 client, I launch Trilium using the trilium-no-cert-check.bat script, which sets the NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable to bypass certificate verification.
Despite this, the client fails to connect to the sync server, displaying the error:

Sync failed: No connection to sync server.

The server is accessible from the Windows client; I can successfully tcping the server on port 65443. Additionally, when I configure the server to use HTTP (https=false), the client connects and syncs without issues.

This issue seems specific to the Windows client when connecting over HTTPS with a self-signed certificate, even when certificate verification is disabled. Interestingly, an Android client using a WireGuard tunnel to the same server syncs successfully over HTTPS.

Steps to Reproduce:
Set up TriliumNext sync server on Raspberry Pi with https=true and a self-signed certificate.
On Windows 10, launch Trilium using trilium-no-cert-check.bat to disable certificate verification.
Attempt to configure sync with the server at https://192.168.88.24:65443.

Expected Behavior:
The Windows client should connect to the sync server over HTTPS, even with a self-signed certificate, when certificate verification is disabled.

Actual Behavior:
The client fails to connect, displaying "Sync failed: No connection to sync server."

Additional Information:
Server Configuration:
TriliumNext running on Raspberry Pi.
config.ini settings:

[Network]
host=::
port=65443
https=true
certPath=/opt/trilium/trilium_server.crt
keyPath=/opt/trilium/trilium_server.key

Client Configuration:
Windows 10 system.
Trilium launched via trilium-no-cert-check.bat:

set NODE_TLS_REJECT_UNAUTHORIZED=0
start trilium.exe

Network:
Client connects to server via WireGuard tunnel.
tcping confirms server is reachable on port 65443.

Any insights into why the Windows client fails to connect over HTTPS with a self-signed certificate, despite disabling certificate verification, would be appreciated.

I'm set TriliumNext client in Chinese, my log shows some Chinese characters.

TriliumNext Version

0.93.0

What operating system are you using?

Windows

What is your setup?

Local + server sync

Operating System Version

C:Windows 10 LTSC 21H2 / S:Raspberry Pi OS bookworm

Error logs

toast.ts:88 14:19:19 error: 同步失败：No connection to sync server.
:37840/#root/_hidden/_options/_optionsSync?ntxId=pyIowP&hoistedNoteId=_options:1 [Intervention] Slow network is detected. See https://www.chromestatus.com/feature/5636954674692096 for more details. Fallback font will be used while loading: http://127.0.0.1:37840/assets/v0.93.0/fonts/JetBrainsMono-Light.woff2
toast.ts:88 14:19:29 error: 同步服务器握手失败，错误：
toast.ts:88 14:23:48 error: 同步服务器握手失败，错误：
toast.ts:88 14:32:35 error: 同步服务器握手失败，错误：
toast.ts:88 14:32:48 error: 同步失败：No connection to sync server.

[dosubot[bot]]

Hi @arizuka! I'm Dosu and I’m helping the Trilium team.

This is a known limitation with Trilium Desktop and Electron apps: setting NODE_TLS_REJECT_UNAUTHORIZED=0 (even via trilium-no-cert-check.bat) does not always reliably disable certificate verification on Windows, due to how environment variables are handled by Electron and Node.js in recent versions. This can cause sync over HTTPS with self-signed certificates to fail, even when the variable is set as documented 1 2.

A workaround that works for many users is to launch Trilium with the Electron flag --ignore-certificate-errors, which disables certificate errors at the Chromium level. On Windows, you can do this by creating a shortcut to trilium.exe, then editing the shortcut's "Target" field to append --ignore-certificate-errors (for example: C:\path\to\trilium.exe --ignore-certificate-errors). Start Trilium using this shortcut and try syncing again 1.

Importing your self-signed certificate into the Windows trusted root store may help in some cases, but Electron/Chromium often does not use the system store, so this is not guaranteed to work 1.

Disabling certificate validation (by any method) is insecure and exposes you to man-in-the-middle attacks. For production or sensitive environments, it's strongly recommended to use a certificate signed by a trusted CA 1.

There are no recent code changes or fixes for this issue; it's a known limitation with current Electron/Node.js behavior in Trilium.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[youli42]

机器人是对的，实际上你可以这样配置Windows快捷方式，这样在使用中没有问题，只是可能存在一些安全隐患

The robot is correct. In fact, you can configure Windows shortcuts this way, and there will be no issues when using them, but there may be some security risks.

target：\Path\To\Trilium\trilium.exe --ignore-certificate-errors