[Bug]: Can't trust custom Certificate Authority, only the self signed certificate

[guillaumedsde]

Checks before filing an issue

• This issue doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• I have checked the issue tracker and have not found an issue that matches the one I'm filing.
• This issue is not a troubleshooting question. Troubleshooting questions go here: https://forum.mattermost.com/c/trouble-shoot/16.
• This issue is not a feature request. You can request features and make product suggestions here: https://mattermost.com/suggestions/.
• This issue reproduces on the most recent stable version, or the most recent prerelease version of the Mattermost Desktop App.
• I have read the contribution guidelines.

Mattermost Desktop Version

5.10.2

Operating System

Ubuntu 24.04.1 LTS

Mattermost Server Version

9.11.8

Steps to reproduce

1. Open the mattermost desktop client and connect to an instance with a self-signed certificate
2. Manually trust the certificate from the popup (which adds the certificate to ~/.config/Mattermost/certificate.json
   
3. The trusted certificate expires and is renewed
4. The popup to trust the certificate appears again

Expected behavior

There should be a way to point the Mattermost desktop client to the custom Authority's certificate instead of simply trusting the TLS certificate (which is bound to expire and be renewed).
Otherwise, the user is prompted to re-trust the certificate every time it expires (which can be frequent in modern environments with automatic renewal) which is not secure.

Observed behavior

A TLS certificate error pops up in the mattermost desktop client every time the TLS certificate of the server is renewed.

Log Output

[2025-01-23 13:19:49.181] [warn]  [App.Utils] Could not get server info for NetOPS Error: net::ERR_CERT_AUTHORITY_INVALID
    at SimpleURLLoaderWrapper.<anonymous> (node:electron/js2c/browser_init:2:117806)
    at SimpleURLLoaderWrapper.emit (node:events:519:28)
[2025-01-23 13:19:49.277] [info]  [MattermostBrowser...] [NetOPS] [TAB_MESSAGING] Invalid certificate, stop retrying until the user decides what to do: Error: ERR_CERT_AUTHORITY_INVALID (-202) loading 'https://█████████████/'.

Additional Information

No response

[devinbinnie]

I don't believe there is a way in Electron to set this up, though as I would understand it I think Electron would check your locally configured trusted certificate authorities to see if a certificate is valid, and only throw an error if it doesn't recognize one of those installed authorities. At least this is how I believe it works on Windows, Ubuntu may handle things differently.

If possible, can you try install the certificate into your OS so that Electron recognizes it as valid? Not sure if this guide would help: https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

[guillaumedsde]

I don't believe there is a way in Electron to set this up, though as I would understand it I think Electron would check your locally configured trusted certificate authorities to see if a certificate is valid, and only throw an error if it doesn't recognize one of those installed authorities. At least this is how I believe it works on Windows, Ubuntu may handle things differently.

If possible, can you try install the certificate into your OS so that Electron recognizes it as valid? Not sure if this guide would help: https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

Thank you for your reply 🙂

I have already added my CA's certificate to Ubuntu's certificate store (by adding the certificate to /usr/local/share/ca-certificates/ and running sudo update-ca-certificates).
I have also tried running mattermost by using the Node env vars which are theoretically used by Electron to point directly to the Certificate:

NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/ca.crt mattermost-desktop

But that does not work either.

[guillaumedsde]

I digged into the mattermost-desktop source code a bit, it looks like the logic implemented for handling self signed certificates implements a simple "if certificate in certificate.json is different from current certificate show error"

desktop/src/main/app/app.ts

Lines 100 to 120 in 0bbf4ef

	} else {
	// update the callback
	const errorID = `${parsedURL.origin}:${error}`;
	const view = ViewManager.getViewByWebContentsId(webContents.id);
	if (view?.view.server) {
	const serverURL = parseURL(view.view.server.url);
	if (serverURL && serverURL.origin !== parsedURL.origin) {
	log.warn(`Ignoring certificate for unmatched origin ${parsedURL.origin}, will not trust`);
	callback(false);
	return;
	}
	}
	// if we are already showing that error, don't add more dialogs
	if (certificateErrorCallbacks.has(errorID)) {
	log.warn(`Ignoring already shown dialog for ${errorID}`);
	certificateErrorCallbacks.set(errorID, callback);
	return;
	}
	const extraDetail = CertificateStore.isExisting(parsedURL) ? localizeMessage('main.app.app.handleAppCertificateError.dialog.extraDetail', 'Certificate is different from previous one.\n\n') : '';

desktop/src/main/certificateStore.ts

Lines 75 to 80 in 0bbf4ef

	isTrusted = (targetURL: URL, certificate: Certificate) => {
	if (!this.isExisting(targetURL)) {
	return false;
	}
	return areEqual(this.data[targetURL.origin], comparableCertificate(certificate));
	};

Perhaps instead of merely checking if the previous and current certificates are equal we could validate the certificate against a CA's certificate?

[devinbinnie]

Appreciate the effort to look at the code, I'll have to spend a bit of time and chat with some people internally on this one.

Created a ticket: https://mattermost.atlassian.net/browse/MM-62733

[guillaumedsde]

I dug a bit further and actually found the "proper" way to add a CA's certificate for use by Electron apps.

TL:DR, its possible to add the CA's certificate to the NSS shared DB with the following command:

certutil -d "sql:${HOME}/pki/nssdb" -A -t "C,," -n my_custom_ca -i "${CA_CERTIFICATE_FILE}"

Then, you can remove mattermost-desktop's "certificate store":

rm ~/.config/Mattermost/certificate.json

Once you relaunch mattermost, Electron will consider the certificate valid and mattermost-desktop's custom certificate handling code (linked above) won't be executed.

This is a functioning workaround, but mattermost-desktop's certificate handling code could maybe be updated to either prompt the user to manually insert the CA's certificate in the NSS store, or the app could do it itself.

[enzowritescode]

@guillaumedsde just double checking, but when you installed the CA certificate in /usr/local/share/ca-certificates/ did you verify that it worked correctly by going to your Mattermost server in a browser?

[guillaumedsde]

@guillaumedsde just double checking, but when you installed the CA certificate in /usr/local/share/ca-certificates/ did you verify that it worked correctly by going to your Mattermost server in a browser?

Hi!

In order to get the TLS connection to the mattermost server working in the browser I had to manually import the CA certificate in firefox. Simply installing the certificate in the system CA bundle using /usr/local/share/ca-certificates/ and update-ca-certificates does not work since Firefox does not trust the system CA certificate bundle by default.

However when installing the certificate using update-ca-certificates, I can confirm that using curl to send an HTTPS request to mattermost works.

[kirik]

TL:DR, its possible to add the CA's certificate to the NSS shared DB with the following command:

certutil -d "sql:${HOME}/pki/nssdb" -A -t "C,," -n my_custom_ca -i "${CA_CERTIFICATE_FILE}"

Thank you, confirmed - this is only way to trust self-signed cert for Mattermost/Electron apps. Only thing - in Ubuntu 25.10 path to db is different by default: ~/.pki/ (hidden directory in home).
So command will look like: certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n *CERT_NICKNAME* -i *PATH_TO_CERT*