Desktop: Connection using certificates not working after restart

[Barben360]

Hello,

I have an issue connecting to a NextCloud server with a (P12) certificate using Linux client, requiring a password. When I start with a fresh new configuration, everything is fine: after attempting to connect unsuccessfully, a choice with different choices of connections is issued to me and I can connect with my certificate and password. The connection is then ok and stable.

But when I exit NextCloud client (when I restart my Linux for instance), it is impossible to connect to my account, without fully removing it and initiating a brand new connection. I tried everything like logging out and in again and it just issues an error (server replied: bad request).

Is that a known issue? It just seems that the connection is attempted without the certificate when the app is restarted.

I attach a log (with modified username and server address) showing a failed attempt of connection.

Best regards.

log_nextcloud_client.log

[Barben360]

Note: the exact same experiment on Windows client does not lead to any problem, the connexion using certificate is ok.

[apolyton]

I have this issue on Windows clients running nextcloud 13.0.1 server with a non standard port (8025) with client version 2.3.3.1 The rest of my issue is the same as described above

[camilasan]

any idea @rullzer @juliushaertl ?

[oceanBT]

same problem here. maybe something with the system keychain ...

[htot]

With 2.3.3.1 on Windows 10 we have the same problem. I looks like the Client does not use the system Certificate Store. When adding the server it asks for the certificate, even though that is already known to the system. ~However, when restarting it seems to have forgotten it need the certificate~. Nevertheless the connection is fine then. After restarting the Client the connection fails and the only way to fix is remove it and add again.

It seems currently Nextcloud Client is supposed to persist the certificate in the Credential Store and that is seems to be currently not working. We tested also using Owncloud Client on Windows 10, which is also not working. Owncloud Client from Kubuntu Bionic is working fine, which is supposedly storing the credentials in KWallet.

It seems the Client maybe using an older version of qtkeychain. This issue maybe related to Windows Credential Store: Use CRED_PERSIST_ENTERPRISE.

[wdehoog]

Just build branch 2.4 (QT 5.11.1 MinGW 32 bits). Problems is as described: failed to login after a restart.

When building qtkeychain with -DUSE_CREDENTIAL_STORE=OFF the certificates are saved in the .cfg file (as PEM) and are loaded after a restart (login works).

[camilasan]

Interesting @wdehoog. I will test it since we are having problems on Windows on storing the credentials. Thanks for the report!

[camilasan]

Awesome @wdehoog, it works for me too :beers:

[htot]

Any chance we can get this in until credentials get fixed?

[camilasan]

Totally @htot. I am exausting my debug skills with this one :cry:... probably today evening I will post a new build here with credentials off.

[camilasan]

Hey all, could you try this build? https://download.nextcloud.com/desktop/daily/Windows/Nextcloud-2.5.0.61352-daily-20180904.exe
It should work with the Windows Credential Manager.
Please, let me know if it works.
Thanks!

[wdehoog]

Tried the new build (20180904). It does not work for me. After importing the p12 file it immediately complains with:

This site can’t provide a secure connection
xxxxx didn’t accept your login certificate, or one may not have been provided.
Try contacting the system admin.
ERR_BAD_SSL_CLIENT_AUTH_CERT

[htot]

Could that be related to self signed certificate? Because that would be a regression.

[wdehoog]

Here is a copy from the logwindow content. I get the impression the certificate is imported and used. It
is able to determine the auth url. But the wizard's webview cannot access it and the setup process cannot continue.
Maybe the wizard''s webview does not use the new certificate.

2.5-setupwizard-log.txt

[htot]

@wdehoog Ah I see. I just tested on linux and can reproduce that _using Nextcloud-2.5.0.20180904-daily-x86_64_. That is a regression as the stable linux client currently works fine with (self signed) certificates.

From the logs it looks like OCC::WebViewPage::initializePage tries to setup a new connection to https://xxxx.xxx/owncloud/index.php/login/flow, either without using the certificate or trying to use the certificate, but it is not yet saved in the credential store at this point.

[wdehoog]

The sad thing is this is already known. See #481.

[htot]

That sucks a bit. Looks like the 2.5 series is still quite far from releasing. Can't we get a fix based on -DUSE_CREDENTIAL_STORE=OFF into stable?

[camilasan]

There is a PR open to fix the self signed certificate #630.

[htot]

Yes, we tested that PR but it does not seem to resolve this issue.

[wdehoog]

There are two problems:

1. The desktop client does not save the imported client certificate so after restart one cannot log in.
2. The webview does not use client certificates at all so the setup process cannot be completed.

How is this PR supposed to solve that?

[camilasan]

1. I couldn't reproduce it (Windows).
2. https://github.com/nextcloud/desktop/pull/630#discussion_r216032671

[wdehoog]

1. You could. The fix was -DUSE_CREDENTIAL_STORE=OFF.
2. The comment you refer to does not seem to be related to client certificates.

[camilasan]

1. I got the same results by properly linking the qtkeychain libs when running cmake (https://github.com/nextcloud/client-building/blob/master/build.bat) - no need for turning off the credential store - and even after restarting I didn't have to login again.
2. The comment is about self signed certificates.

[wdehoog]

1. Yes it is about self signed certificates. Probably one that comes from the server. So the PR could make the webview accept a self signed certificate sent by the server.

The issue on this page is about self signed certificates being sent TO the server. In our setup the Nextcloud server only accepts connections when they use a valid client certificate. Each client must send it with their requests. The desktop client can do this (if it was able to store it), the webview (using QWebEngine) cannot.

[misch7]

Fixed in the 2.6.1 release, see #863 :)