Within the enterprise environment, occasionally some hosts are served with corporate internal CA. And, these root certificates are registered in each device user store.
But obsidian (android) looks only trusts certificates in the system store.
So, retrieving web content or accessing server with some plugins (e.g., ReadItLater, Auto Link Title, or Self-hosted LiveSync), failed.
I know it’s disabled by default since API level 24.
But if you add “user” to certificate src, It would be very useful.
I renamed this thread to clarify its intent. For anyone who stumbles upon this thread in the future, allowing this will let whoever provided you the root certificate (state or corporate) to spy on you (perform a men in the middle attack).
You are right to be concerned. That’s right, if an untrusted root certificate has been installed, may MITM works.
On the other hand, it’s also true that some people want to access the endpoint that is non-secure or signed by a local CA.
For example, in a corporate environment, it may be used for various reasons, and the same is true for local testing.
Of course, it is safe to prohibit access to all addresses, but is it possible to add a feature to register addresses that may be accessed as an “allowlist” and not prohibit access to those addresses?
I am in need of this feature as well. I am using the remotely-sync plugin to sync to a local webdav server that I’ve secured with my own CA that I run at home. I’ve installed the root cert on my wife’s Android phone, and it seems to be working fine for other apps, but obsidian does not allow the plugin to connect over https, so I can’t sync files with her. I’m able to connect & sync using the same configuration on my iPhone. Would love for this to be supported, otherwise I’ll have to create an http webdav option for this use case, which would be less secure than https + self-signed cert.
I also support this one.
Today I was really shocked when I found out that Obsidian cannot tolerate self-signed certificates even if I have my CA certificate installed on the Android device.
So far, Obsidian is the only app I had this problem on my phone. All other programs accept self-signed certificates just fine.
I second this too. I agree there is a valid security concern but forbidding the self signed certificate is also affecting other valid scenarios too. I set up Nextcloud in my local network using my generated certificated. I can connect to it using Nextcloud client on iPhone. There is a warning the first time when I connect to it. I think this may be a better experience in Obsidian too. Let the user to decide whether to trust the certificate or not. The certificates banned by the browsers are different. They are not self signed certificates anf they were assigned by a trusted organization. The browsers don’t ban self signed certificates at all. There are warning before I accept the certificate.
Banning the self signed certificates in Obsidian is worse, because I have to either use Obsidian or us http which is worse. I’ve been using http endpoint in my local network to use remotely sync. It seems like it’s stop working in recent Obsidian update. It seems to me there is no way to sync now.
@WhiteNoise many android apps trust user added CAs. To give a few examples: bitwarden, home-assistant, nextcloud already have it enable. If someone have physical access to device to install CA they have access to all the data alraedy
the reason given to not include this is hilarious, even self hosted password managers have this as optional.
How can someone else spy on my device when I have access to the device and I am the one who installed it in the first place ?? it doesn’t make any sense
http is enabled by default but I can’t use http since the iOS doesn’t allow it and I can’t use https because obsidian doesn’t allow it.
I am stuck in between, how in the world is this missing in this software, have the devs gone crazy ??
You may be given a device from a company or you may be forced by a company or a state to install a third party certificate on your phone.
I am gonna mention something in this thread because I don’t see anybody talking about it. You can obtain a properly signed certificate for your services using a free service like let’s encrypt.
@vorotamoroz I am using a subdomain which is behind cloudflared tunnel, and using the obsidian-livesync is nightmare especially when we are syncing the device for the first time, it is so slow especially with Customization Sync turned on. But when I use locally then it works very well. Super fast.
Since it seems we are not getting the user-sipplied root cert feature on obsidian. And the iOS doesn’t allow http. Then atleast there should be an option for platforms like Android, PC, macos to take advantage of the local address. Optionally allow us to enter the localaddress and change it later to public subdomain.
This is true, although I disagree with the option not being there, I can’t argue with logic behind it and do admit I have been meaning to setup a properly configure wildcard certificate for a long time
For everyone else, essentially (off the top of my head, will be performing over next few days):
Purchase a domain
Point that domain at your public IP address, create NAT / Port Forwarding rules in your router to forward TCP 80 to the machine you will be running certbot on (certbot issues the certificate by essentially sending traffic to itself on the machine you run it on using the domain name to see if you really own it)
Follow a guide of your choosing for generating a certificate using certbot, their website is very easy to follow and has options for most occasions (even wildcards like what im going for) Certbot Website
Use those files generated to secure your couchdb, whatever obsidian is trying to communicate with
Close the port forward
Alternatively, spin up a random linode or cloud vm of your choice (and point the domain at it) and get the files that way, once your are on your private network your DNS resolver (if you configure it to do so) will give the private IP addresses, all the system cares is that the CA is valid and the dns entry matches the domain name. Although IIRC requests to your public IP from private will just come back anyways but could be some NAT tomfoolery depending on your routing setup
You would only need to open the port 80 once a year to renew the certificate, which there are scripts for, you can then turtle up and close all inbound ports without issue once you have the crt / key / ca files
Not an expert, just a hobbyist, please correct/clarify any mistakes I made
I think support for user trusted CAs should be added, maybe disabled by default.
The main reason is: if I, on my device, add a certificate authority as trusted, it is not your duty to protect me
And btw I already use it with all other synchronization systems, so I would be compromised anyway.
I think this should be a valid enough reason to allow this, without me (or anybody else) having to explain my specific use case and reason why I want this setup.
Anyway, here it comes: the services I use are inside a private network, with its own dns resolver and certificate authority; the domains used do not even exist in the www.
I don’t want (or cannot) register the domains, and have to maintain publicly trusted certificates when I don’t need them.
I fully trust the private authority, or I wouldn’t use this private network.
I do not want (or cannot) open the private network to the outside world only to obtain letsencrypt certificates (this being a security issue way worse the the hypothetical MITM attack from a CA that I trust)
If I may add, on iOS I can sync just fine using this domain, so it makes even less sense not having this possibility on android.
I would love to see this implemented too. I have about 20 subdomains on my internal network that are secured under my self-signed CA. This is the only app that doesn’t accept my CA even though it’s installed in Android. I can’t afford to buy a wildcard CA.
Just going to jump in here and reiterate what benegetto said: blocking user installed certs is worse overall for security. It’s trivially easy to allow, it could be enabled by an off-by-default option with a warning, and by disallowing it you are forcing those of us who use self hosted or enterprise services to compromise our security by either broadcasting aspects of our internal networks to the world to get a publicly readable LetsEncrypt cert or to disable encryption entirely. And the only threat this really defends against is someone who already has access to the device and therefore all of the data in Obsidian anyway.
It’s all very well and good to demonise self signed certificates, but all security practices exist in a context and need to be understood in terms of their threat model - a browser not trusting self signed certs by default is safe because that would let websites execute man in the middle attacks, an app refusing to trust even verified user certificates is unsafe because it forces insecure workarounds and does nothing to actually prevent MITM attacks (since the channel is already as secure as that user’s security practices)
I don’t particularly need this feature myself, but I don’t agree with the reasoning behind its refusal. Self-signed certs are perfectly fine as part of a secure private network operated by someone who knows what they’re doing. Making this be a default-disabled option and including the caveat that enabling may weaken security, would be more than enough to serve the needs of those who need it while keeping those who don’t need it from any (remote) chance of compromise.
Having to declare it isn’t a barrier to having it off by default - the default off option is to address the concerns about adversarial device certificates (which IMHO isn’t a real security threat in that anyone with the capacity to install device certificates already has access to the device and therefore the Obsidian vaults anyway, there’s no additional protection). Increased scrutiny on Google Play feels like even more of an excuse when there’s tons of examples of apps that have no trouble offering user certificates (Nextcloud for an example of an app that by nature contains a ton of sensitive data and is developed by a very conscientious team). Google’s paranoia around user certs related to apps automatically installing CA certs either with no user intervention or obfuscated user intervention - those capabilities have been removed from Android though. Google’s real concern with user mode certificates would be if you included a guide in the app explaining how to install a cert with no explanation of the security implications.
