Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
6 tasks done
guillaumedsde opened this issue Jan 23, 2025 · 5 comments
Open
6 tasks done
Labels

Comments

@guillaumedsde
Copy link

Checks before filing an issue

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
    Image
  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
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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') : '';

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
Copy link
Member

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants