I use Nextcloud in a private network with a private domain and a self-signed certificate.
This setup has always worked fine — but now, suddenly, the client refuses to sync.
The error says:
A problem occurred during the SSL protocol: The certificate is self-signed and therefore not trusted.
How can I disable the certificate check in the Desktop Client?
Or is there any other way to make self-signed certificates work again?
Same problem here.. I installed the previous Version again and disabled update.. I hope this will be fixed soon.
FYI @mgallien
How did you install the old version?
Do you have to delete the current version first? That would mean having to resynchronize everything, which is quite a lot of.
Or can you just install the old version over the new one?
This is a killer bug for me. I need to use the sync client on my computer which hosts the Nextcloud server. I’m going to have to dump Nextcloud if I can’t get a solution.
And I’m using an ssl cert from a supplier - valid and NOT self-signed. Still get ssl errors on machines connected to my LAN and on the server machine’s client. Works fine outside my LAN.
Basically, the Nextcloud client won’t work with http://localhost/nextcloud or http over my trusted LAN.
I just had this problem. This is so bad! Totally unusable!!!
The version 3.17 totally destroyed all self-hosted instances. There is no way to connect!
So then I assume you’re also using a valid registred domain name. If Nextloud is running on the same host as the desktop client, you could add the following to your hosts file…
127.0.0.1 cloud.yourdomain.tld
…and then use your actual domain name instead of localhost.
Btw, regardless of whether this is actually a bug, I’d recommend that everyone ranting in this thread take a look at 101: Split-Brain DNS (Split Horizon)
A proper split-brain DNS setup allows you to use the same domain name/URL inside and outside your local network, which has several advantages. For example, when creating and sharing links or if you have mobile devices that sometimes connect from inside your local network and sometimes from the internet.
Why do you make that assumption? A lot of people just self host on a server at home with dynamic DNS. It works perfectly fine with previous Windows client. The client will prompt users to “trust” the certificate at the first time. There is nothing wrong with this approach.
My reply was mainly directed at @montanaviking, and according to his posts, he has a valid certificate but isn’t using it on the LAN. I only mentioned “everyone in this thread” in passing because you’ve mostly been ranting and making sweeping generalizations, and just wanted to vent your frustration. So I wanted to address you directly, while still posting something potentially helpful for you and others who might read this.
No, not all of them — only those without proper certificates, allegedly. Otherwise, please describe exactly what your problem is, your setup, and which certificates you’re using. If the issue is reproducible, you or someone else can open an issue on GitHub.
Just jumping in and saying “Fuuu, totally unusable, all self-hosted instances destroyed!” doesn’t help solve whatever issue there might be with 3.17.0.
And yes, of course you can do whatever you want, but if you’re not willing to contribute constructively, then maybe don’t use Nextcloud. At this point, I couldn’t care less.
But, in case you want to stay a little longer, maybe install an older 3.16.x version in the meantime, and if you really want to hlep, open a bug report on GitHub.
Please define “proper certificates.” Since when self-signed certificate with a dynamic DNS is considered improper? And why all of a sudden version 3.17.0 took extra effort to block those self-signed certificates without a warning?
Yeah, you got me there:
“Valid certificate signed by a public certificate authority” would have been better.
The rest of my post still stands. And yes, it’s probably a bug in the client, but since I’m using a valid certificate signed by a public certificate authority, I can’t reproduce it. So someone who can reproduce it will have to open a bug report, if none exists already.
Workaround: use an older version until it’s fixed.
I would suggest dropping the word “valid.” It is more proper to just say “certificate signed by a public CA” as you can’t claim that self-signed is invalid.
For people who self-host at home, getting a CA signed certificate is not practical. Some ISPs block port 443. Even if one managed to get such a certificate, it is endless trouble to share the certificate with many applications behind NAT port forwarding, and inherently much more insecure.
So, it is definitely a bug that needs to be fixed.
So I must be doing something wrong, then. You’re aware that Let’s Encrypt exists, right? I believe it’s been around since 2016. (I haven’t googled it.) 
Yes, I agree that self-signed certificates should still be an option, also and especially for testing purposes. However, for production use, particularly if the service is accessible via the internet, I personally think it’s worth spending 10 bucks a year on a domain name. After all, the certificates themselves are free.
Still too much trouble. Like I said, my ISP blocked port 443 and 80. Also sharing certificate among servers is a pain. Reverse proxy is also a pain. I would just prefer simple. And there is actually no security risk with self-signed for me.
The DNS challenge exists extaley for that usecase. But yes, I understand that you want to use self-signed certificates, and I agree that this should be possible.
However, ‘too much trouble’ is generally a pretty lame argument, so you probably shouldn’t use it too often — especially if you want to get people on forums to help you or developers working on FOSS projects to solve an issue for you.
Unless you can prove that using self-signed certificates poses significantly higher risk for me, it is groundless to convince me to move to CA signed. So if it’s secure, who do anybody want to bother with anything else?
Well, one reason could be that self-signed certificates simply don’t work anmore with certain products, and we’ll probably see that more often in the future, especially with mobile apps. But again, I agree with you that it should still be possible, and I don’t think it’s intentional in this specific case, so we don’t need to discuss that part any further.
Of course, in such cases you could probably still run your own CA and import the root certs into the certificate stores of the respective OSs and devices. But let me guess: “too much trouble”. So maybe paying 10 bucks a year for a domain and using the DNS challenge will actually be less trouble in the long run.
Also, certificates serve two separate purposes. One is transport encryption — and that works even with a self-signed certificate. The other is authentication/identity — ensuring the certificate is valid for a specific domain and signed by a trusted authority. That second part only works with a trusted CA, whether public or your own CA. Whether you need that in a home network is debatable, but personally I go with a proper certificate anyway, if only to avoid the constant certificate warnings — that alone makes it worth the effort to me.