Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No option to accept self signed certificate #672

Open
1 task done
ramos opened this issue Feb 13, 2020 · 9 comments
Open
1 task done

No option to accept self signed certificate #672

ramos opened this issue Feb 13, 2020 · 9 comments

Comments

@ramos
Copy link

ramos commented Feb 13, 2020

The option "Add trusted certificate" of webdav repository does not allow to use a self signed certificate unless the CN field matches the FQDN. This is inconvenient for dynamic IP servers. Is there any workaround?

  • I have searched for existing issues that may be the same as or related to mine.
@nevenz
Copy link
Member

nevenz commented Feb 25, 2020

I'm not finding a way to remove just that check. Perhaps someone else knows if it's possible, without adding an option to allow any certificate (which probably shouldn't be done).

@ramos
Copy link
Author

ramos commented Feb 29, 2020

Well, in this case I would really add the option to allow any certificate. Webdav is specially useful with self-hosted solutions (i.e. nextcloud/owncloud), and in many circumstances this involves a self signed cetificate that works with a dynamic IP. Not many choices here...

Could this option be added after advising that this is a risk?

@somini
Copy link

somini commented Apr 5, 2020

If you have a self-hosted instance, get a certificate using Let's Encrypt. If you manage your server yourself, use the certbot daemon to keep it fresh.


If you really want to add a self-signed certificate (and you shouldn't), why not add it directly to Android's cert store? That way it works on all applications.

https://support.google.com/pixelphone/answer/2844832?hl=en-GB

@ramos
Copy link
Author

ramos commented Apr 5, 2020

Thanks for the points. Unfortunately I do not own a domain. I do not have a fixed IP. Getting a certificate seems impossible under this situation.

I have the self signed certificate installed. Still it does not work.

Finally, although I perfectly understand the generic statement "you should not use self signed certificates", I am starting to be tired of this mantra. This is my home server that I would like to use when I am on the move (ssh, backups, etc...). Nobody else uses this machine. I install my self signed certificate when on my local network, and I am done forever. Works like charm in many applications: ssh, web, etc... Honestly, I find it difficult to understand why such an easy thing is not allowed after warning the user to be careful with what they are doing...

@somini
Copy link

somini commented Apr 5, 2020

Without a domain this is indeed impossible. No fixed IP is not a problem, that's my setup too. You just setup a script to run every 5min that changes the IP on DNS, if needed. This is called DDNS, I
use Hurricane Electric for this.

The script is just curl -4s "https://dyn.dns.he.net/nic/update" -d "hostname=$HOSTNAME" -d "password=$PASSWORD", running on the RPi under my TV.

Domains are cheap, if you steer clear of memorable names and regular TLD.

Having a domain also let's you share stuff with other people, and they don't have to install the self-signed certificate.

Honestly, I find it difficult to understand why such an easy thing is not allowed after warning the user to be careful with what they are doing...

Because if you lose control of that private key, you can create a certificate for "github.com" that your devices accept. If you can't assure that https://github.com connects to a Microsoft-owned machine, nothing is true and everything is permitted. It's not that you lose confidentiality for your domain, you lose it for every domain.

While the private keys for CA that browsers include by default have the keys under literal lock-and-key, 24h surveillance and the whole shebang.


We are veering away from the purpose of this issue, so if @nevenz wants me to shut up please say so. 😀

@nevenz
Copy link
Member

nevenz commented Apr 30, 2020

I'm not finding a way to remove just that check.

Scratch that, it's possible by overriding HostnameVerifier when creating OkHttpClient in WebdavRepo. A check against user-defined patterns could be added.

I don't know if it's a good idea though. But after supporting the addition of trusted certificates, we might as well support this too.

@nevenz nevenz removed the New label Jun 24, 2020
@farynaio
Copy link

farynaio commented Aug 20, 2022

I'm not finding a way to remove just that check.

Scratch that, it's possible by overriding HostnameVerifier when creating OkHttpClient in WebdavRepo. A check against user-defined patterns could be added.

I don't know if it's a good idea though. But after supporting the addition of trusted certificates, we might as well support this too.

@nevenz Can you create a PR?

@ugurbolat
Copy link

would be interested in self-signed certificates as well for WebDAV server in the local network...

@CataCluj
Copy link

Syncing with NextCloud through WebDav and the self-signed certificate is the first thing I tested when I installed Orgzly.
Without it it's no use to me.
Joplin has a checkbox; let me know when you do that too; I might try it again if I don't move to something else by then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants