Well.
First things first: custom CA doesn’t weaken security. period.
Second: I found a way to use custom certificate on linux.
I extracted distributed AppImage, and straced the binary.
It turned out obsidian checks nssdb at $HOME/.pki/nssdb/ for certificates.
So you can use certutil to add your custom certificate there.
Example:
certutil -A -n “example.net” -t “CT,C,C” -d /home/generalro/.pki/nssdb/ -i /path/to/ca.pem
After that I was able to use “Remotely Save” plugin with s3 endpoint with custom cert.
I found this thread after spending hours trying to understand why my chinese androind table won’t allow to connect to my selfhosted couchdb server…
I don’t want to create any polemic here but to me it looks like a bug, if Android allows users to add their own CA, why would an application from this ecosystem refuse to use this capability?
I originally thought the issue was with the livesync plugin, that it didn’t support self-signed SSL due to a synchronization error. To my surprise, the root cause was actually Obsidian. This really leaves me speechless.
In my country , if our server isn’t registered, access to port 80 is not allowed by default. There’s no way to use Let’s Encrypt. At the same time, our DDNS service provider is not supported by Certbot, which is a disaster. I have to purchase an additional domain name and manually install the SSL certificate on the server every three months.
I also strongly support this request and need this feature.
If anyone’s still looking for a solution, I whipped up a simple ReVanced patch which can be found here.
The patch enables the Obsidian Android app to trust user-supplied CAs which in turn allows the excellent self-hosted LiveSync plugin to work with self-signed certs.
I’ve done some minimal testing with a few of my own devices and everything seems to work fine.
I am also shocked this is not supported by the app.
I agree with the above, in that protecting the device from untrusted certificates is out of scope of an app. That is a wetware-level problem at best. The whole point of Android supporting user-defined certificates is to enable a user to pass on CA’s they deem to be trustworthy such that downstream applications and services can access them. All from one central trusted repository.
If security is really the scare here (again, this is not weakening security, it’s using an item that - by definition of being in the user-defined store - is already trusted), then add an optional field to validate the remote server’s fingerprint, chain of trust, or something. Whatever makes you sleep easier at night. But this is silly, not using a built-in feature of Android.
This is a major make/or/break “bug” for me. I really don’t want to rely on patching apps (Thanks for putting together the ReVanced patch though, @Faith001), but it looks like I have little choice if I want to continue using Obsidian.
@WhiteNoise Your messages sound like excuses for not adding this feature. IMHO, you need to reconsider your position. This request is open a long time ago and people really need this feature.
In many applications, the use of self-signed certificates (e.g., NextCloud, Bitwarden) is allowed, and this does not create issues in any app stores. If you are concerned about users, it is sufficient to inform them about the risks associated with using such a certificate, but ultimately, the user must make the final decision themselves.
Indeed: Custom CA doens’t weaken security. Another alternative: If you hava a rooted device with Magisk installed. You could install the self signed CAs to your user store and install the Magisk-Module “AlwaysTrustUserCerts” in Github.
I have not verified yet, but I would assume the equivalent Windows keystore works as well.
On Android, the same block that appears to keep the android app from using custom CAs also seems to block it from accessing user-provided mTLS certificates, though my ability to test this theory is limited without console access. I’m working on a plugin where I really want mTLS to work, and I have a setup that works in the desktop app, but that refuses to work on the mobile app. Works fine in FF and Chrome, both with a direct web request and with a fetch().
For good measure, I hard-coded a fetch request that I used in all 5 cases (FF/Chrome direct, FF[1]/Chrome fetch, Obsidian):
// Obsidian variant
fetch("<redacted>/", { credentials: "include" }).then(msg => msg.text()).then(msg => new Notice(msg)).catch(err => new Notice(err));
// Everywhere else variant (mainly tested against jsbin for console access on mobile):
fetch("<redacted>/", { credentials: "include" }).then(msg => msg.text()).then(msg => console.log(msg)).catch(err => console.error(err));
FF/Chrome on Android both passed after requesting a mTLS certificate for all four combinations, but obsidian fails without ever asking for a certificate. The https certificate in this case is signed by certbot, so the only problem is the mTLS certificate. The certificate is only in the Android system store, so ignoring user keys would explain the problem.
mTLS in particular should be easier to bypass, as least with desktop plugins[2], because some node clients support directly providing mTLS certs.
By default, uBlock Origin has very strict defaults that causes the request to fail. I had to whitelist the site I tested on to get it to work. Something something localhost protection? Neat feature, though the one time it did anything, I needed it to not do anything ↩︎
Bypassing it on desktop is not currently needed, though, precisely because ~/.pki is respected. Bit of a weird decision to support it on desktop but not mobile, so if this disappears at some point, alternate clients do work. They may work on mobile too with this approach, but a whole 20 seconds of research failed to find any obvious clients that supported it. I’m leaving that bit as a problem for future me. Bit more annoying though, because it involves going outside the standard keychains, but whatever ↩︎
Hi everyone,
First of all, I really love Obsidian! It has completely changed how I organize my notes and tasks. Recently, I wanted to take things one step further by sharing notes and to-dos with my family. After some research, I discovered the Self-Hosted LiveSync community plugin, which seemed perfect for what I wanted to do.
So… I went all in:
I bought a Raspberry Pi 5 and taught myself some Linux to install DietPi.
Then I managed to set up CouchDB in Docker, learning a ton along the way.
I even created self-signed certificates so that all traffic runs securely over HTTPS, and everything synced perfectly on all the laptops at home.
But when I finally installed Obsidian + LiveSync on my Android smartphone, I hit a wall: although my phone can access the CouchDB server via HTTPS, Obsidian doesn’t seem to support self-signed certificates.
It’s frustrating to be so close to the goal!
Would the Obsidian developers consider adding support for self-signed certificates? It would make setups like this much more accessible for users who want a fully self-hosted and secure environment, without exposing it to the internet.
If you’re on macOS, you can add your self-signed certificate root to the System keychain in Keychain Access and Obsidian will trust it. Note that it has to be the System keychain under System Keychains, not just a manually-trusted certificate under either the login or Local Items keychains. You’ll probably have to restart Obsidian for it to take effect.
Have been considering using obsidian for a long time. Have been self hosting stuff for a year now, and decided to give it a go. I’m so glad I decided to check whether obsidian would be okay with self signed certs, feels like I dodged a bullet here. I’ll wait another year or something and see if there’s been any progress on this.
No question… in a corporate environment this is absolutely mandatory. Every organization i work for use a local PKI and it is mandatory to trust the root certificate of this PKI. Without this internally self hosted sync is not possible. Most times there is no other option … by policy. A show stopper …
Yet another user here who would greatly benefit from the feature. I agree that enterprise environments are the greatest point in favor of this, but this would be great for us hobbyists too. I run my own CA at home and use my certs for all other services, as this allows me to use easier-to-type domains running on my own intranet.
As for the reason why I use self-issued certs, it is mainly for getting a strong sense of ownership over my infrastructure, a sentiment I believe resonates with the core philosophy of this software’s development team: “own your notes, your data is yours.”
I got here from trying to use the Obsidian Live Sync plugin, but I then discovered that user installed CAs are an opt-in feature implementation within the network security configuration (since Android 7 it seems). While I understand some may consider this feature to result in security vulnerabilities, I think there are a few things that could be done to mitigate that, like putting the feature behind a runtime toggle, with warnings for people who want to use it anyway.
I’d deeply appreciate a developer response for this, so we can at least expect to get this feature in the future. If it is not at all planned, it would also be good for us to know, as to put the idea to a rest.
Love your guy’s software, and thank you for the attention!
As this is the only answer from a member of the obsidian team I’d like to answer. I made an account just for this.
Every Browser can use user supplied certificates when activated in advanced settings. Why should Obsidian be under scrutiny for doing the same?
This Post has relatively many views, likes and the Issue it addresses is of high importance for the self-hosting community. Isn’t that enough traction to motivate the addition of a hidden setting? (So the poor and vulnerable user doesn’t accidentally go to a Kazakhstans’s website after it manipulated him to authenticate and confirm the addition of a user certificate.)
Why would you shoot down a users request with an argument like that instead of getting an actual statement or reference stating that you can’t do this?
Certificates don’t just get trusted on your phone without the user being informed meaning the user has to actively trust the certificate it has been provided. If a user wants to trust something why would you forbid that?
Having to get a public domain to do some SSL with my private server is silly as heck. This is a viable workaround but not a satisfying solution.
I can’t even edit the post but deleting seems to work a few times.
What is this??
How do you think of someone abusing delete and restore but not think of editing posts?
This isn’t “not thinking”, it’s spam protection. When you are no longer a brand new user you will have more forum privileges like editing. Spammers editing links into their posts is extremely common and very tricky to spot.
