Configure Proxy and Root CA store in Cryptomator settings and provide defaults for shared devices

[SailReal]

Please agree to the following

• I have searched existing issues for duplicates
• I agree to follow this project's Code of Conduct

Summary

Allow users to configure the Proxy and Root CAs used in the Cryptomator settings and provide a location for defaults on shared devices.

Motivation

More and more companies are protecting their infrastructure by exposing as few services as possible to the public. This is also true for Cryptomator Hub. If you deploy Cryptomator Hub on https://hub.leela.local for example, you will face two main problems:

1. Even if your system trusts your Root CA which issued the certificate for hub.leela.local, Cryptomator will not. Instead, you need to modify the cacerts file bundled with the application as described in Error RKM7:2TU1:BGIR #2619 or modify the Cryptomator.cfg and override the Root CA store via option:

   java-options=-Djavax.net.ssl.trustStore=/path/to/your/truststore
   

2. You may need a Proxy to connect to hub.leela.local. Cryptomator is shipped with the setting to use the Proxy configured in the system. If you do not want to configure it globally, or your system does not support it like most Linux desktop environments, you need to configure it in Cryptomator.cfg like this

   java-options=-Djava.net.useSystemProxies=false
   
   java-options=-Dhttp.proxyHost=hub.leela.local
   java-options=-Dhttp.proxyPort=3000
   java-options=-Dhttps.proxyHost=hub.leela.local
   java-options=-Dhttps.proxyPort=3000
   java-options=-Dhttp.nonProxyHosts=localhost|127.0.0.1|*.leela.local
   

The problem is that you have to change this on every release, which results in repackaging the applications, breaking the signature of the applications and adding a lot of complexity to the update process (Windows, MacOS, Linux) just to configure a Proxy and use different Root CA(s).

From a user perspective, it would be good to configure the Root CA(s) and Proxy settings in Cryptomator's settings so that the values are persisted, as many applications do, e.g. Firefox:

Also, if you think about shared managed devices, an IT admin should be able to place a template file for these properties into the system, persistent across updates and for all system users, so that when a new user logs on to the device, these properties are read from the shared location. After all, in this common scenario, which end user knows the correct configuration of the Proxy and the certificates of the Root CA(s) when they sleepily log on to their shared device for the first time on a Monday morning and would also need to have admin privileges?

Maybe we find a better way, but we could have a shared settings.json placed outside the user context, and on startup this is merged with the user specific settings.json where you can overwrite any values.

---

We try to prioritise issues as much as possible, but if you need this feature in a more timely manner, you may want to consider sponsoring this feature. Contact us at support@cryptomator.org for more information.

With sponsored features, the requirements are driven by the sponsor, but the resulting feature is available to everyone using Cryptomator. Instead of custom work, sponsors are willing to contribute features back to our platform so that all Cryptomator users can benefit! Also, sponsoring a feature is cheaper than custom development.