(Bug report) trilium-no-cert-check.sh still get Error: net::ERR_CERT_COMMON_NAME_INVALID

[PDiracDelta]

Trilium Version

0.62.5

What operating system are you using?

Ubuntu

What is your setup?

Local + server sync

Operating System Version

22.04

Description

I'm connecting on a local network (where my server is), so naturally my cert for example.com gets declined as I'm connecting through 192.168.1.x and I get Error: net::ERR_CERT_COMMON_NAME_INVALID
However, after using /usr/lib/trilium/trilium-no-cert-check.sh I still get the same error. Why?

Update: even after connexting externaly, I still get Error: net::ERR_CERT_DATE_INVALID (again because my cert is out of date). So it's a general issue where trilium IS performing cert checks while it shouldn't.

Error logs

Error: net::ERR_CERT_COMMON_NAME_INVALID
Error: net::ERR_CERT_DATE_INVALID

[perfectra1n]

Whatever shell you are using, you can try setting NODE_TLS_REJECT_UNAUTHORIZED to 0.

e.g.

export NODE_TLS_REJECT_UNAUTHORIZED=0

Validate that you have set the variable in the shell where you're executing Trilium:

echo $NODE_TLS_REJECT_UNAUTHORIZED

Trilium isn't doing any special checking as it's using Node.js's defaults. The NODE_TLS_REJECT_UNAUTHORIZED variable comes from here. It sounds like to me that the variable isn't getting propagated to the program at runtime. But the .sh does work as expected. Check out some more docs here.

Or just set up sync with an IP address instead of a hostname.

[PDiracDelta]

Whatever shell you are using, you can try setting NODE_TLS_REJECT_UNAUTHORIZED to 0.

e.g.

export NODE_TLS_REJECT_UNAUTHORIZED=0

Validate that you have set the variable in the shell where you're executing Trilium:

echo $NODE_TLS_REJECT_UNAUTHORIZED

Trilium isn't doing any special checking as it's using Node.js's defaults. The NODE_TLS_REJECT_UNAUTHORIZED variable comes from here. It sounds like to me that the variable isn't getting propagated to the program at runtime. But the .sh does work as expected. Check out some more docs here.

Or just set up sync with an IP address instead of a hostname.

Thanks for the info. Unfortunately, this also doesn't work. Even after setting that variable, running trilium.sh nor trilium-no-cert.check.sh works.
The console logs this:

[12926:1123/132318.690956:ERROR:cert_verify_proc_builtin.cc(702)] CertVerifyProcBuiltin for pdiracdelta.ddns.net failed: ----- Certificate i=0 (CN=pdiracdelta.ddns.net) ----- ERROR: Time is after notAfter

The thing is, I'm using docker, so I can't even control the certificate... can I?

[PDiracDelta]

UPDATE: it works with trilium --ignore-certificate-errors rather than the trilium-no-cert-check.sh binary.
Of course, I'd reeeaaally prefer a secure connection...

[perfectra1n]

Glad you got it sorted out! Your external cert should work (when making a request to your public IP from inside your LAN) due to NAT hairpinning. This is exactly what I do on my network with port forwarding :)

Again, glad you got it to work though! Feel free to close the issue then.

[PDiracDelta]

Glad you got it sorted out! Your external cert should work (when making a request to your public IP from inside your LAN) due to NAT hairpinning. This is exactly what I do on my network with port forwarding :)

Again, glad you got it to work though! Feel free to close the issue then.

Well thanks, though my problem still isn't solved, I'm not able to set up an automatic secure sync. I just managed to do 1 manual sync...

NAT hairpinning is useful, but not the issue here. The executable does not work as intended, so I will not close the issue.
Also, I cannot even do a manual sync on Windows as it seems start trilium.exe /no-cert-check is not the way to pass the parameter correctly (if it is even supported on Windows).

[perfectra1n]

Zadam isn't making many changes nowadays on this repo, so you may want to check out the updated fork at TriliumNext/Notes. See #4620

[perfectra1n]

My suggestions would be to change your server to use http:// instead of https:// so that you don't have to fight the self-signed issue (which you can do via the config.ini). Unless you think you're going to be MITM attacked within your own LAN, I don't see a practical use case for being against just using http:// for the server sync.

I don't believe that flag is supported on the Windows client currently.

[PDiracDelta]

My suggestions would be to change your server to use http:// instead of https:// so that you don't have to fight the self-signed issue (which you can do via the config.ini). Unless you think you're going to be MITM attacked within your own LAN, I don't see a practical use case for being against just using http:// for the server sync.

I don't believe that flag is supported on the Windows client currently.

OK thanks for the info and that's a very good point, I don't expect MITM on my LAN :D so at least I can start syncing my local devices.