Recent linux client versions break access to server (certificate related)

[user23498723452]

I've rebuilt my Ubuntu desktop (new 18.04) and I've downloaded the appimage from Nextcloud for the client.

Unfortunately I'm unable to connect to (setup new connection to) my local server likely due to a certificate related issue, that appears new to the client historically. I have a traditional Ubuntu PPA client package that is not having this issue on Ubuntu 16.04. (I am not testing re-creating my server connection from the client - so this issue may have been created in some version of that client AFTER I connected it)

I'm seeing a similar error as in #718 , and I do have an intentional certificate mismatch.

error seen in browser

Error seen in logs (unclear if it is directly related - could be normal for authentication - unknown)

Sabre\DAV\Exception\NotAuthenticated: No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured

My server version should be irrelevant since simply changing the client to use the LE cert Common Name "fixes" the issue. But if you need to know - I'm running 14.0.3.

The ability to ignore cert issues is required due to the simple architecture of home-based networking. The public certificate is accessible at the public facing router, and routing (via loopback routing) all internal traffic thru that places an unnecessary and impossible load on it ( I have hundreds of GB to sync). There needs to be support for direct server access (such as possible when you ignore certificate warnings). There is also no way that anyone is building a split-dns architecture to support using the public name, while routing it directly internally. The right fix is to permit certificate warnings to be ignored.

Testing the actual name for the Let Encrypt cert proves the client can function.

What is the fix for a client to connect to a server with a certificate that has some type of trust issue (like a self-signed cert or direct IP access since there is no private/internal DNS)?

Is there a client option to ignore the cert trust issues? The cert popup normally raised seems to have no impact to the issue (when I mark it as trusted).

Effectively, I view this change to the client as unacceptable and a breaking change that needs an option to workaround.

[user23498723452]

Similar to #960 and #279

[user23498723452]

I've identified the exact error that needs to be added into the code touched in #758

Also, you should enable logging of the error number somehow. To capture something that users can report to you. See qwebengine error info

This is a showstoppper for anyone relying on direct private IP access to a publically accessible service. And yes, it is a showstopper.

[user23498723452]

NextCloud Support Team, my issue has been ignored all year. Can I please just get someone with some certificate knowledge to look into this?

[misch7]

There were a lot of SSL related issues with the web-view component, used in older clients and servers.

That's why we implemented a new Login Flow v2 to address this issue, to login via the standard browser instead. The new flow is available only with the 2.6 Desktop Client and Nextcloud server 16 or newer.

[user23498723452]

Thanks for the response @misch7 . I managed to figure out that I could simultaneously have both the old 2.3.3 snap installed along side the current nextcloud-devs PPA install. I have confirmed that the certificate with a non-matching hostname (it connects to an IP instead) is permitted once again.

Because my issue has been ignored for so long, and it is unclear what the future holds for "untrusted certificate" (including self-signed) support - can you officially clarify what the team will support going forward?

I found it very unacceptable to have my solution broken and unsupported for almost a year - given it was a showstopper for ME. I need to know if the product team is planning on permanently supporting these scenarios or not. Because I'll move on if this is going to be an ongoing issue where there is no QA testing of common use cases from existing users.

[misch7]

Thanks for the response @misch7 . I managed to figure out that I could simultaneously have both the old 2.3.3 snap installed along side the current nextcloud-devs PPA install. I have confirmed that the certificate with a non-matching hostname (it connects to an IP instead) is permitted once again.

I'm not sure if I understand your question correctly, but with client 2.6 and server 16+ you should be able to connect even if the certificate's common name doesn't match the domain name. For example I'm doing this all the time when I connect to my local Docker test environment by either providing a local IP address or a "fake" domain name like "nextcloud.lan" and have not run into any problems. The client complains - as expected - about the domain name mismatch and displays a warning, displaying the certificate information. Then I'll allow an exception, as I would on a web browser and connect:

And also with a fake, non-matching domain name (extended warning):

To make this work you need to add the domains you want to use to your NC server's
config/config.php, example:

$CONFIG = array (
...

  'trusted_domains' =>                                           
  array (                                                        
    0 => '127.0.0.1:8080',                                       
    1 => 'nextcloud.lan',                                        
    2 => 'fake-domain.lan',                                      
  ),

...
);

Otherwise the server will refuse connections from non-trusted domain names.

In general if you work with self-signed certificates, you should set up your own certificate authority to sign your client certificates. It's more trustworthy and if you add the CA to your browser (like I did) you don't get warnings there. Setting up a simple CA is not that hard, I followed these instructions:
https://www.ssltrust.com.au/help/setup-guides/client-certificate-authentication

The warnings are meant to keep you secure from someone tampering your connection. But if you for some reason need to work with these hacks, well the 2.6 client does that for you with the new Login Flow 2 of the NC 16+ server ;-)

[user23498723452]

Thanks for the followup. My point is I have done this in the config. For YEARS. My concern is there have been multiple failures by "the team" to properly support the capability you mention. At times causing outright showstoppers.

I'm asking if the team is committing to providing (and testing!) this functionality going forward.

[misch7]

I really don't get your point. As you can see these features are quite up-to-date, the whole login Flow v2 has been implemented just recently because of this kind of problems, and of course the client is actively developed and tested (!). Seems like you just need to do your part too and should also more often test recent versions of the client and server to benefit from these enhancements.

[user23498723452]

I don't disagree that a fix has been found for the issue. The main problem is how we (users) revisit this topic multiple times. Telling a user to participate in manual testing of something like this seems unhelpful to actually solving the repeated issues encountered. Users aren't nearly as reliable as an automated process. And it is clear, historically, that fixing this takes many weeks (or months!) each time. Which means a showstopper that the user cannot fix and they are forced to retreat to older versions - which are poorly supported!

Are you able to point to any test cases (for certificates) in your public repo? I'd really like to confirm this. This really seems like something that should be automated, although I may be ignorant in what is possible here. I can happily open a new issue to request testing of these cert issues, if that would be more appropriate.

[misch7]

What do you mean?
What kind of test cases?

And what manual testing is unhelpful? Of course you have to test with your NC instance manually, how wouldn't you?

[user23498723452]

Testing the applications ability to connect a client to a server that is using an invalid certificate. So testing any of the common well known use cases of certificate related problems. Such as incorrect hostname or expired certificate. Not only for connecting, but for setup of the connection to the server in the client app. (which is where this issue cropped up)

[claell]

@misch7 I think what @user23498723452 means is testing new releases for functionality to make sure not to introduce regressions with future versions for this component (broadly what https://en.wikipedia.org/wiki/Test_automation describes). I guess also something like unit tests and continuous testing.

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[github-actions]

This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you!