WebDAV / isWebDAVWorking error messages: possible explanation with respect to certificates

[mmattel]

There are many threads regarding error messages above which confuses many people. I was confused too but after digging around, I found some stuff I would like to write down to bring light into darkess and maby help finding a solution for getting rid of this kind of "error" message. Even this error message appears, owncloud client sync works without problems.

If you look into ./lib/private/util.php you find
public static function isWebDAVWorking()

in this function, following parameter is set
$client->setVerifyPeer(false);

Further on in
./3rdparty/sabre/dav/tests/Sabre/DAV/Client.php

the above parameter "false" is assigned to
$curlSettings[CURLOPT_SSL_VERIFYPEER] = $this->verifyPeer;

Now we could think, that this would do what we want, but we still get a error message logged.

Here is what I found could help understanding:
According: http://stackoverflow.com/questions/13740933/security-consequences-of-disabling-curlopt-ssl-verifyhost-libcurl-openssl

snip...

CURLOPT_SSL_VERIFYPEER: checks that the remote certificate is valid, i.e. that you trust that it was issued by a CA you trust and that it's genuine.

CURLOPT_SSL_VERIFYHOST: checks that the cert was issued to the entity you wanted to talk to.

To compare it to a real-life scenario, VERIFYPEER is like checking that the form of ID is one that you recognise (i.e. passport from a country you trust, staff card from a company you know, ...). VERIFYHOST is like checking the actual name on the card matches who you wanted to talk to.

snip...

I saw that the parameter $curlSettings[CURLOPT_SSL_VERIFYHOST] was never set. I gave it a try and added a line to Client.php right after where CURLOPT_SSL_VERIFYPEER was set
$curlSettings[CURLOPT_SSL_VERIFYHOST] = 0;

And voila, the error message disappeared.

Having that explained, how does that look into a particular host environment?
Here is mine and maybe that helps. I have a signed certificate (and a self signed one to play around).
The signed certificate (I used a free service) was created for my domain, let´s call it www.mydomain.com. My provider forwards both mydomain.com and www.mydomain.com to the same IP address. If I do a http (or curl) request to www.mydomain.com, I do not get error messages, if I do the request to mydomain.com the error message appears.

If you look now to the statement above regarding VERIFYPEER and VERIFYHOST things get now more clear.

VERIFYPEER returns a positive result because the certificate is signed
VERIFYHOST returns only a positive result if the request matches the certified hostname / domain name

The same is true for self signed certificates

You can do a test by using following command, depending how you created your certificate:

sudo curl -v mydomain.com/owncloud/remote.php/webdav
sudo curl -v www.mydomain.com/owncloud/remote.php/webdav

-v ... verbose
-k ... test ssl insecure (eg for self signed certificates)

Maybe the $curlSettings[CURLOPT_SSL_VERIFYHOST] parameter can be set in user.php but I have not tried this. What I also looked for is, if there is a wrapper for this parameter like for CURLOPT_SSL_VERIFYPEER in Sabre 1.8.7 which has not been merged up to now, but it isn´t ( @DeepDiver1975 )

[PVince81]

Wow, thanks for the detailed analysis.

Linking with #6275 which shows the message for different reasons.
We should probably change the message.
Even better if we manage to fix the verifyhost you've mentioned, as it would reduce the number of cases where the warning happens.

At some point I was thinking about moving isWebDAVWorking() to the JS side and try connecting to WebDAV with Ajax, but I'm not sure whether it would work properly with "invalid" self signed certificates.

[mmattel]

I am not that good in PHP so forgive if I request nonsense...

Maybe you could set the $curlSettings[CURLOPT_SSL_VERIFYHOST] parameter at the place where you set $client->setVerifyPeer(false), or extend the sabre class. The owners of Sabre should be contacted to implement a wrapper for the host part. That would fix this on a long run. @DeepDiver1975 will update Sabre to 1.8.7 but there is no wrapper included, and 1.9 is in early stage and a wrapper could be requested making it consistent. This would lead in the ability to check things in detail by setting the variables as we need.

Anyway, if there is a chance to define the host part in OC, we should use that and document this accordingly.

And yes, there are other Sabre error messages than those related to certificates. But eliminating these would be a big step forward as we then could focus on those who may cause real problems.

[Niduroki]

@mmattel #8181 implemented CURLOPT_SSL_VERIFYHOST, can we close this now?

[mmattel]

I will close this. I tested #8181 which is working great.
Also thanks for opening a PR at https://github.com/fruux/sabre-dav/pull/437 fixing this on a long run.

[Niduroki]

@mmattel about fruux/sabre-dav#437 and fixing in the long run … take a look in there yourself 😄

[mmattel]

Impossible - is just a opinion... 😃