Support self signed certificates for federated shares

[zeus86]

Steps to reproduce

1. Share a file via Link in Instance A
2. Open Link
3. Click "Add to your Nextcloud"
4. Enter Address of Instance B

   Expected behaviour

In case of a Certificate not trusted by the OS of instance B (aka. selfsigned): Popup that says "Cert not trusted, continue anyway?"

Actual behaviour

Action aborts due to the fact, that the Certificate is not trusted

Nextcloud version: 10.0

Updated from an older Nextcloud/ownCloud or fresh install: fresh

Of course not all users, using NC are able (or willing) to add certificates of other instances with self-sign-cert to the trusted certs of the OS of their NC-Instance. On the one hand is not every user admin on the installation he or she uses, and on the other hand might this cause problems within larger setups, which are used internal only without access to the internet.

Of course i aggree that in case of public reachability something like letsencrypt shall be used (which is not always possible and might be a hassle with dyndns on home setups), and that company-networks shall use own CAs, which are installed on all productive machines, but the bitter truth is, that this is not the case, so it sould be at least possible to dismiss certificate-warnings (at least because of an untrusted signing CA) if needed, like it is in browsers.

[nickvergessen]

I guess that is not possible. Especially the "popup" part.

But maybe @LukasReschke knows more

[zeus86]

the acutal way "how" to notify the user is not important, but there should exist a way to do some "interconnect" anyways, regardless of the certificate.

[fishscene]

I agree completely with @zeus86. Self-signed certs should not be a problem. This is actively halting a setup I am working on. I initially reported this in the nextcloud snap: https://github.com/nextcloud/nextcloud-snap/issues/81

Original post:

Federation: Can't add trusted nextcloud server if SSL Cert is self-signed.

I was attempting to run a test to link 2 snap installations of NextCloud with federation, but the following error was generated: cURL error 60: SSL certificate problem: self signed certificate

Self-signed certs aren't a problem. Maybe a warning perhaps, but not a problem. Why would a server admin need to rely on outside parties to verify an internal server is what it says it is?

It would seem to me that an override option should be available, preferably with the cert displayed for manual verification. After all, I trust my servers. :)

Nextcloud Snap 9.x on Ubuntu 16.04.

[Ouack23]

Same issue here : Nextcloud fresh install 10.0.1 Apache configured properly Self signed certificate done properly following these instructions : https://jamielinux.com/docs/openssl-certificate-authority/

This is really annoying, as it is what nearly every nextcloud admin want to do ! Really looking forward for a fix for this.

[fishscene]

This is flagged as "Needs info", but I'm not sure what information is needed.

In sum: As an administrator federating 2 servers, I should be able to vouch my servers are who they say they are.

How this is communicated to the person federating the server doesn't matter. As long as there is an override and a way to see the certificate that needs to be accepted (for manual verification).

[schiessle]

This is really annoying, as it is what nearly every nextcloud admin want to do ! Really looking forward for a fix for this.

I would argue, that what every admin wants is a valid SSL certificate. Look for example at what your browser will tell you if you open a public link if you use a self signed certificate. Most recipient of such a link will probably close the browser and never get the file.

What's the use case / reason to use self-signed certificates?

[zeus86]

the use-case is e.g. inhouse use. many people set up an NC-box for their parents or other people not so familar with computers, you don't want to check for certs there all the time, but you also dont want to blast plaintext-PWs over the lan. another reason are people which are using dyndns-providers. it is often a hassle to stick certs to that, simply because now and then a dyn-provider closes the service or wants money from now to then and you change the provider including addresses. testing is of course another usecase. i dont want to care a lot about certs for temporarily testing instances. and finally there are networks - intentionally or not - which are not connected to the internet and dont use an own CA.

your experience may vary, but these are at least my top-selling points. nextcloud is not a business-only-product, but for the crowd, the community also. and there, at the community ARE some not-so-rare usecases for having selfsign-certs. there is a reason why you can dissmiss cert-warnings in browsers: only because your browser doesn't know what the issuer of an cert is, does not mean that it is insecure. it just means that i dont want to run a certificate-infrastructure for a web-cloud-project!

[fishscene]

@zeus86 You are on-point in all cases.

Not including a method to trust the certificate is a loss of functionality in the trust model. Essentially, administrators, developers, and integrators are being forced to rely on a 3rd party infrastructure when they should be able to rely on their own infrastructure.

[STonEDSTonE]

I am also interested in this. I have setup NC for myself with LetsEncrypt because i also have it available from the internet, but also installed another NC for my parents which is just internal and therefore i used selfsigned certs. Now i can't share the christmas pictures with my parents through federated cloud sharing because of this bug. Is there a workaround? an SQL-Statement or sth. to manually accept the server? Or add the cert to ressources/config/ca-bundle.cert?

[powerpaul17]

What's the use case / reason to use self-signed certificates?

Simply put: "My data, my way."

I am also sick of endless curl error messages about "not matching hostnames" and "self-signed certificates". There really should be an option to accept these certificates anyway. Because it is "My data, my way." ;)

[nickvergessen]

https://github.com/nextcloud/server/issues/2917#issuecomment-276073498 should help

[powerpaul17]

Thank you, but I already tried that. Still getting the "does not match target hostname" error.

[STonEDSTonE]

I used sudo -u www-data php /var/www/nextcloud/occ security:certificates:import ~/cert.crt to import the cert. But when i try to add the other server (https://192.168.178.50), it says "kein Server zum Verbinden gefunden" which translates to "No Server found to connect to". In the logs it creates the following entry: Error federation No server to federate with found Both Servers are on the same Network (192.168.178.0), one has the selfsigned cert mentioned above and the other one has a valid lets-encrypt cert with a valid dns-entry (xxx.ddns.net).

If i try to share a file directly with Name@FQDN, i get constant notifications about a file being shared on the other server but the file never shows up, and the logs show: Error core cURL error 51: SSL: unable to obtain common name from peer certificate Error PHP Error: Call to a member function getMimetype() on boolean at /var/www/nextcloud/apps/files_sharing/lib/Controller/RemoteController.php#115

does Federated Cloud Sharing only work if both servers have a valid FQDN?

[Zerod159]

Simply put: "My data, my way."

I am also sick of endless curl error messages about "not matching hostnames" and "self-signed certificates". There really should be an option to accept these certificates anyway. Because it is "My data, my way." ;)

I think, that would be the best way.

[nikinname]

I agree. I have the very same problem with famili NC servers. I think that something like "allow exception" for the self signed certificate is absolutely necessary. I had the same problem with NextCloud it is not a new problem. I apreciate a lot the great work made by nextcloud developers. I assure that for home, dyndns installation the certificate problem is not a small one.

[michelmalle]

Same Problem appears when you try to create a federate share to a server which uses Letsencrypt certs...thats annoying. I do absolutely agree to @zeus86 idea to create that "Cert not trusted, continue anyway?" button for e.g.

Please add this feature, NC guys!

[nickvergessen]

Letsencrypt works fine here, maybe your root certs have not been updated in a while?!

[jn-se]

Same problem for me as reported by @michelmalle. I'm still using Ubuntu 14.04 and so I probably don't have the right root certs. [Updated: Lets Encrypt is now working. Failed due to a misconfiguration.]

But nevertheless there should exist a suitable method of approving self signed certificates on the administration pages. There seems to be a parameter that is not working (see #4452).

[FlorianHeigl]

1) at least in my test occ security:certificates:import ...cert.pem didn't do anything (correction: it had a permission issue that blocked it, but it didn't tell the path. some guessing helped) 2) you can use self-signed certs if you properly put them on your system, but self-signed certs are a thing of the past, and a really good idea in 2003 at least have signing CA (3 more steps) 3) what you should be asking for: it should be possible to import a foreign cert if its encountered on import. your connection could still be intercepted by whoever's in between at that time, but it's better than '-k' at curl, which means you can be attacked every time, just because you don't care.

accept & Import self-signed: not too bad, your data, your responsibility turn off validation: grossly negligent (that's the term for it, no matter what you think about it)

[wioxjk]

Any progress with this?

[kyrofa]

2917 (comment) should help

occ security:certificates:import <cert> doesn't work for me, either.

[kprkpr]

How is going this? In NC23 continues to being a problem We are using a two nextcloud instances (One internal and other external), and the internal uses self-signed cert, and we can't federate it, and then we can't share documents from intranet to external nc (External and internal NC can be seen between)

[wck86]

I'll join the chorus on this issue... I support part of massive ad-hoc network that provides high speed digital services to first responders and incident response teams. Others like me have NC servers that we would like to federate, but we can't due to this limitation. Not being able to federate with other regional emcom providers hampers our effectiveness serving potentially critical public safety activities. Could this be addressed with a pair of simple checkboxes in this section, toggling whether self-signed certificates are allowed and whether regular http, insecure servers are allowed?

[Uatschitchun]

I join in here. I've got 3 NC servers running:

A: local docker install running behind traefik as reverse-proxy with LE certificate B: Install on a shared hosting environment with certificate from: CN = Encryption Everywhere DV TLS CA - G2, OU = www.digicert.com, O = DigiCert Inc C: Install on uberspace with LE certificate All 3 are running NC27

Federated sharing results in: A -> B (not working) A -> C (working) B -> A (working) B -> C (working) C -> A (working) C -> B (not working)

So sharing from either A or C to B isn't working and gives:

Fehler: Exception: Freigabe von Federation fehlgeschlagen, da user@myserver.de nicht gefunden wurde. Möglicherweise ist der Server nicht erreichbar oder nutzt ein selbst zertifiziertes Zertifikat. 

This, although there's no self-signed certificate involved.

I also tried importing B's certificate with occ security:certificates:import on A and A's certificate on B to no avail ;(

I'm not sure, but the error message refers to the server one is sharing to and not the one one is sharing from, correct? So there's something wrong with B's certificate?

How am I able to solve this? As said, no certificate is self-signed, all servers use https and all 3 have the other 2 as trusted server although all are yellow!? Yes, I did occ federation:sync-addressbooks an all of them.

[skjnldsv]

We already have a config for this: sharing.federation.allowSelfSignedCertificates Set it to true :+1:

[zeus86]

I really did not expect this issue to be solved after 8(!) years.

[FlorianHeigl]

Well at least you got told that the feature already exists as if it had been there all the time :-] Now, on to build something!

zeus @.***> schrieb am Fr., 27. Sept. 2024, 01:32:

I really did not expect this issue to be solved after 8(!) years.

— Reply to this email directly, view it on GitHub https://github.com/nextcloud/server/issues/1413#issuecomment-2378117917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVSVGYZ6BEKHZXGD4LMCOLZYSKSBAVCNFSM6AAAAABOPQ27FOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGEYTOOJRG4 . You are receiving this because you commented.Message ID: @.***>