Allow user-supplied root certificates (weaken security)

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.

Could you possibly consider it?

Edited: Moved into Mobile Category


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).

Something like this:

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?

This would be very helpful.


2nd this.

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.

1 Like

Update: I switched to using a public domain + cert and then restricting it to local only access as a workaround.

1 Like

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 :slight_smile:

1 Like

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.

1 Like

@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):

  1. Purchase a domain
  2. 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)
  3. 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
  4. Use those files generated to secure your couchdb, whatever obsidian is trying to communicate with
  5. 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.

  1. I don’t want (or cannot) register the domains, and have to maintain publicly trusted certificates when I don’t need them.
  2. I fully trust the private authority, or I wouldn’t use this private network.
  3. 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.