element-desktop
element-desktop copied to clipboard
Add a way to trust self-signed certs
At least when you are building as an electron app it would be nice to have a way to trust self-signed certs
Certainly we can't do this in the in-browser app, as it's very much up to the browser.
I doubt we can do it for the electron app either, but maybe @dbkr knows differently.
At the end of the day, Letsencrypt is a thing, and probably a better solution than self-signed certs anyway.
This might help: http://electron.atom.io/docs/api/app/#event-certificate-error
So it'd be possible to subscribe to that event and then, well, either verify it or not, based on user input
Hello, im not too sure where the code for that would go i tried editing it into the main.js but when i do the console no longer shows the insecure error but it still shows the trusted error on the main app.
Nevermind i gave lets encrypt a go and it worked out beautifully.
I also have this problem. Let's encrypt is not an option for me (DS-Lite and DynDNS problems).
@tschopo what OS?
Ubuntu 16.04
Linux is the difficult one in this case sadly
why is that?
because for Windows and Mac electron supports firing the System UI for trusting certificates. For Linux we would need to write our own code for that
Just tried under windows 8.1. Here there is also no way to trust the certificate.
I didn't say its being called. I'm saying it CAN be, its a feature of Electron, for Linux it doesn't support it so would require a lot more work. In Windows/Mac you can trust it using the OS System settings and it'll work anyway, in Linux I don't think thats guaranteed to work
I can work around this issue by adding --ignore-certificate-errors when starting riot-web.
It's probably more likely blocked on upstream support
I cant use the Windows Desktop 0.17.3 because of self signed certificate warning. the --ignore-certificate-errors does not Work with Windows. How can we use the beta riot Windows Client with self signed certificates?
Trust the cert in a browser / the os itself
By OS may be working but why in 'a' browser? There should be no link between Firefox (for example) and the Windows App. I should also working like the android App to trust easily self signed certificates.
Browsers should add it to Windows certificate store which the chromium engine inside the windows app will read from
No. FF for Example has its own certificates management and nothing to do with Windows certs. IE 11 want not load the site with the error: DLG_FLAGS_INVALID_CA DLG_FLAGS_SEC_CERT_CN_INVALID I guess IE11 can manually add his cert with some mouseclicks, but there is no cert-automatism.
Hi,
are there any news on this topic. We need that feature for our intern matrix server. We don't have the server connected to the internet so Let's Encrypt is no option.
Regards Martin
Same here! Please add an option to import own CAs!
Same here. Our users VPN in to use riot against local matrix (synapse) server. Any updates?
I found a working solution with a selfsigned certificate and the Windowsdesktopapp Elements. First you have to create a FuelChainCertificate. Here is a link how you can create one with OpenSSL. After you have created the Root and Intermediate certificate you have to create the server certificate. I followed also the instructions, which I found on this side. However, some adjustments were necessary for me. In my case it was not necessary to enter the URL without any errors with this instruction alone. I have to enter the IP-Adress of my server as subjectAltName. For the csr-Request I configured a san.cnf-File. And I append the server_cert_ext.cnf - File from the mentioned turtorial above with the entire content of the san.cnf file. Example san.cnf [req] default_bits = 4096 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [dn] C = ST = L = O = OU = emailAddress = CN = example.com [req_ext] subjectAltName = @alt_names [alt_names] IP.1 = x.x.x.x
After that I was not able to connect to my server via the hostname but now I can connect with https://ip-adress. I gues my hostname failed because I do not have a FQDN because I do not have a domain :D Hope that helps
I found that my self-signed certificate worked out of the box on NixOS's build of Element. There were two things that were important here:
- The signing certificate is added to the system trust store (
/etc/ssl/certs/) - the certificate contains the domain as
SubjectAltName. A domain inCommonNameonly is rejected by electron.
If these are not sufficient, specifying the --use-openssl-ca option to electron might help.
I haven't tested whether the certificate also works for federation (assuming the other server trusts it), but that would be a synapse issue rather than an element issue if not.
I doubt we can do it for the electron app either, but maybe @dbkr knows differently.
Wouldn't this work?
const { app } = require('electron')
app.commandLine.appendSwitch('ignore-certificate-errors')
I think it's crazy Electron lets you totally headshot certificate errors, but not specifically add an extra CA.
Feels like a real slap in the face regarding security.
I'm trying to trust an org CA for this instance of Electron/Element-Desktop specifically, I don't want to add it to the system's cert store.
As mentioned in https://github.com/matrix-org/synapse/issues/5152#issuecomment-1532280232, to connect with my .onion hs I need to run Element Desktop version 1.11.30 with --ignore-certificate-errors parameter. The same HS run with Element Web (on element.io) connects without sweat, although the browser (Chrome) turns the padlock icon red as "your connection to this site is not secure", which I accept as Tor provides another means for privacy.
Firstly, I would much more prefer a relevant option in config.json to either ignore certificate checks completely or create a whitelist of trusted hosts about which electron should not make fuss if a self-signed certificate is presented.
Eventually, I would also like self-signed certificates to simply be acknowledged and handled favorably. Please also note, that on Element Android, when a non-trusted certificate is presented by the server, the client simply asks the user whether it should be accepted. Seems only plausible to expect a similar user experience on both platforms.
While this continues to be an issue, I've dug up a better temporary solution (on an old stackoverflow post) than --ignore-certificate-errors which compromises security.
To reiterate from that post, you can install your self-signed certificate into the NSS database using certutil (part of libnss3-tools on debian-based systems), like so:
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "My Certificate" -i path/to/my.crt
Note: The -t "C,," flag sets it as "Trusted CA" for purposes of SSL only (see man page for certutil)
Chromium (and by extension Element) appears to be using this database, as this has solved the issue for me.