I am using davfs2 v1.3.0 which I compiled from source. I am trying to connect to a server with a self-signed certificate. Every time I try connect to the server, davfs2 tells me that it doesn't trust the certificate:
/sbin/mount.davfs: the server certificate does not match the server name
/sbin/mount.davfs: the server certificate is not trusted
...etc...
I am trying to get rid of this message. So I stored the certificate in pem format in ~/.davfs2/certs and pointed servercert in davfs2.conf towards that file. According to the man page this should help: "when a server presents this cerificate it will be trusted without trying to verify it." But no joy, it still tells me that it does not trust the certificate. I also tried storing it in /usr/local/davfs/etc/davfs2/certs/ and even /etc/ssl/certs. But none of this helps, davfs2 keeps hassling with this question. Am I doing something wrong here? Any help would be appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
/sbin/mount.davfs: the server certificate does not match the server name
/sbin/mount.davfs: the server certificate is not trusted
issuer: WebFaction, London, GB
subject: WebFaction, London, GB
identity: web29.webfaction.com
fingerprint: cb:ad:1f:a0:7b:e8:ed:58:5c:31:29:3d:a3:74:e9:b6:e7:28:f7:42
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]
Error message with "servercert" configured:
/sbin/mount.davfs: the server certificate does not match the server name
issuer: WebFaction, London, GB
subject: WebFaction, London, GB
identity: web29.webfaction.com
fingerprint: cb:ad:1f:a0:7b:e8:ed:58:5c:31:29:3d:a3:74:e9:b6:e7:28:f7:42
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]
After configuring "servercert" davfs2 does trust the certificate (no more error: "the server certificate is not trusted"). But this does not help, because it is the wrong certificate. (error message: "the server certificate does not match the server name").
The certificate is for "web29.webfaction.com", but the server is "webdav.nublado.org". The server must present its own certificate, that is: Common name (CN) of Subject must be "webdav.nublado.org". Using the identity card of your older sister will not help, even if it is valid.
Cheers
Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The server might be faked or there might be a man-in-the-middle-attack": you must have a very strange definition of "trusting"....
Anyway, you are not telling me anything new here. I have no control over the certificate that the server presents me. So how do I tell davfs2 to "really trust" the certificate and not keep hassling me with this question every time?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I have no control over the certificate that the server presents me.
> So how do I tell davfs2 to "really trust" the certificate and not keep
> hassling me with this question every time?
You can't. But you can tell the server administrator to clean up the mess. Or you can patch davfs2 to accept any garbage.
Again: your server comes up with the certificate of his older sister. davfs2 trusts the certificate (it is not a fake). But davfs2 is not stupid enough (like your ordinary doorman), not to notice that it is the certificate of someone else.
Cheers
Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the patch, but I really think that a fix should be part of the distribution.
To stay with your doorman analogy... Even after the doorman has been explicitly told by the owner of the club that a particular guy is trustworthy and should be let in despite his shady looks, the doorman still won't let him in and goes back to the owner over and over again and asks him every time "should I really let him in? he might be an imposter...". What do you think would the owner think of such a doorman? Do you really think he would call him clever?
The program is right to notice the discrepancy and post a warning, but if the user explicitly states that the situation is above board and that the certificate should be trusted, the code should accept that judgment and don't ask the question again. After all, the user knows far more about the situation than the program does. Other programs behave in exactly that way (e.g. ssh, svn, firefox, etc...).
Posting the same question over and over again is counter-productive. All you achieve is that people learn to pay no attention whatsoever to the warning any longer. And when eventually a real problem arises, they are going to ignore it because they have learned to do exactly that. It is essentially the story of the boy who cried wolf. There is a lot of wisdom in that story...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You missed the point: it is not about trusting the certificate. The problem is, that the certificate does not belong to the server.
Please tell me:
What was the reply of the server administrator, when you told him about this? You are sure, it is o.k. that the server uses the certificate of another server?
The problem is on the server side, and that is where it should be fixed.
There is nothing to be fixed on the client side (except the man page could be more definite about this). The client *may* offer an option to accept foreign certificates from certain servers permanently, but there is no must at all. And it needs some care and user information to not open up a security hole. If anybody has time to implement this, he is welcomed.
Security problems with TLS/SSL do not arise from useless warnings, that train people to ignore them. They arise from people just wanting to get connected, and ignoring the warnings from the beginning. And they arise from people not understanding certificates. So, why did you not tell me from the beginning, what the problem is (a server with a certificate from another server). My assumption: you did not know, what the problem is, and you did not care.
Cheers
Werner
P.S.: And don't tell me about firefox and Co. Faking "SSL-secured" websites is successfull. One reason: browsers make it too easy to click away warnings permanently without investigating the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q - What was the reply of the server administrator, when you told him about this? You are sure, it is o.k. that the server uses the certificate of another server?
A - They have their answer posted on their website. It basically boils down to "hand us over a sum of money every year and we will fix it for you". Presumably you then get a certificate signed by some commercial company. That is complete overkill for us, we don't need that.
Also, they are not using the certificate of another server. The certificate is simply using a different alias of the same server. You can check that both have the same IP address. This server is hosting many different domains, which are also constantly changing. They have one self-signed certificate for each physical server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Also, they are not using the certificate of another server.
> The certificate is simply using a different alias of the same server.
If it is just an "alias", you can use this aslias in the URL to connect to the server and there will be no problem.
But it probably isn't. Looks like buggy virtual hosting. But note: neither the clients nor the protocol have to care abaout virtual hosting. Two different virtual hosts are two different servers. And your server uses the certificate of another server. Note: "server" does not refer to some piece of hardware, but to the service.
> It basically boils down to "hand us over a sum of money every year and we will
> fix it for you".
Yeah. You have the choice:
- free beer, that does not serve you well
- buy (better) beer for money
Your choice:
Developers of free software have to make the free beer taste fine? But I am more of the "freedom, not free beer"-persuasion.
Cheers
Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using davfs2 v1.3.0 which I compiled from source. I am trying to connect to a server with a self-signed certificate. Every time I try connect to the server, davfs2 tells me that it doesn't trust the certificate:
/sbin/mount.davfs: the server certificate does not match the server name
/sbin/mount.davfs: the server certificate is not trusted
...etc...
I am trying to get rid of this message. So I stored the certificate in pem format in ~/.davfs2/certs and pointed servercert in davfs2.conf towards that file. According to the man page this should help: "when a server presents this cerificate it will be trusted without trying to verify it." But no joy, it still tells me that it does not trust the certificate. I also tried storing it in /usr/local/davfs/etc/davfs2/certs/ and even /etc/ssl/certs. But none of this helps, davfs2 keeps hassling with this question. Am I doing something wrong here? Any help would be appreciated.
Truncated error messages are mostly useless.
Please send the full error messages
a) without configuring "servercert"
b) with "servercert" configured
Additional usefull information:
The server-URL (as in /etc/fstab)
The servercert in textform (i.e. what you get from "openssl x509 -in cerfilename -noout -text")
Cheers
Werner
Error message without configuring "servercert":
/sbin/mount.davfs: the server certificate does not match the server name
/sbin/mount.davfs: the server certificate is not trusted
issuer: WebFaction, London, GB
subject: WebFaction, London, GB
identity: web29.webfaction.com
fingerprint: cb:ad:1f:a0:7b:e8:ed:58:5c:31:29:3d:a3:74:e9:b6:e7:28:f7:42
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]
Error message with "servercert" configured:
/sbin/mount.davfs: the server certificate does not match the server name
issuer: WebFaction, London, GB
subject: WebFaction, London, GB
identity: web29.webfaction.com
fingerprint: cb:ad:1f:a0:7b:e8:ed:58:5c:31:29:3d:a3:74:e9:b6:e7:28:f7:42
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N]
The server-URL:
https://webdav.nublado.org
The servercert in textform:
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
d0:bb:dd:bf:ce:c7:ec:c4
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, L=London, O=WebFaction, CN=web29.webfaction.com
Validity
Not Before: Feb 9 00:07:42 2008 GMT
Not After : Nov 5 00:07:42 2010 GMT
Subject: C=GB, L=London, O=WebFaction, CN=web29.webfaction.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b2:c8:ca:c0:1e:ff:76:2c:6a:ec:95:98:0e:d3:
8b:d9:0b:b1:7d:a9:94:20:aa:b7:b2:1f:94:58:7b:
01:c5:f2:fb:e9:36:4a:83:26:a5:d3:2c:68:53:7d:
db:9b:e1:e0:6e:02:7a:86:e9:30:db:2b:72:8b:a7:
7a:90:4a:8c:09:8b:e5:35:64:c0:ba:47:95:90:0c:
09:ee:cd:09:02:5c:7f:82:fb:65:5f:19:0e:9b:64:
45:e8:a1:52:ba:df:3d:65:da:7b:05:02:3b:1d:f0:
f5:f4:86:8a:db:a9:36:40:b7:fe:ab:76:a4:7f:70:
63:c3:12:b8:95:a3:fa:38:e9
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
4f:9e:5f:95:1d:05:f8:eb:0a:ff:61:fa:c7:e4:9c:17:6c:77:
12:0b:f9:18:ac:cb:9f:d0:88:a5:b4:57:b2:13:a5:e4:68:05:
b7:10:de:36:9e:b2:3b:8a:e8:60:77:d5:09:12:5a:6d:0b:f7:
f4:62:32:3d:65:a2:a9:cd:e9:e9:90:e8:ea:b2:8e:02:5d:87:
98:5e:62:12:98:7d:ed:8f:bd:17:03:d1:58:00:37:07:04:61:
4e:59:f6:62:cd:ad:9c:c2:ec:ab:05:8f:ac:ba:be:6d:04:2a:
03:31:d8:ac:44:46:f2:7f:b2:ae:78:57:bc:1f:a2:4d:8e:ee:
dd:6e
After configuring "servercert" davfs2 does trust the certificate (no more error: "the server certificate is not trusted"). But this does not help, because it is the wrong certificate. (error message: "the server certificate does not match the server name").
The certificate is for "web29.webfaction.com", but the server is "webdav.nublado.org". The server must present its own certificate, that is: Common name (CN) of Subject must be "webdav.nublado.org". Using the identity card of your older sister will not help, even if it is valid.
Cheers
Werner
"The server might be faked or there might be a man-in-the-middle-attack": you must have a very strange definition of "trusting"....
Anyway, you are not telling me anything new here. I have no control over the certificate that the server presents me. So how do I tell davfs2 to "really trust" the certificate and not keep hassling me with this question every time?
Thanks!
> I have no control over the certificate that the server presents me.
> So how do I tell davfs2 to "really trust" the certificate and not keep
> hassling me with this question every time?
You can't. But you can tell the server administrator to clean up the mess. Or you can patch davfs2 to accept any garbage.
Again: your server comes up with the certificate of his older sister. davfs2 trusts the certificate (it is not a fake). But davfs2 is not stupid enough (like your ordinary doorman), not to notice that it is the certificate of someone else.
Cheers
Werner
Here is how to run SSL with the first "S" removed.
In the davfs2-sources, file src/webdav.c, about line 1818, insert two lines at the very beginning of function ssl_verify.
static int ssl_verify(void *userdata, int failures,
const ne_ssl_certificate *cert) {
/* What the hell is authentication? */
return 0;
Don't tell anybody you've got it from me.
Cheers
Werner
Thanks for the patch, but I really think that a fix should be part of the distribution.
To stay with your doorman analogy... Even after the doorman has been explicitly told by the owner of the club that a particular guy is trustworthy and should be let in despite his shady looks, the doorman still won't let him in and goes back to the owner over and over again and asks him every time "should I really let him in? he might be an imposter...". What do you think would the owner think of such a doorman? Do you really think he would call him clever?
The program is right to notice the discrepancy and post a warning, but if the user explicitly states that the situation is above board and that the certificate should be trusted, the code should accept that judgment and don't ask the question again. After all, the user knows far more about the situation than the program does. Other programs behave in exactly that way (e.g. ssh, svn, firefox, etc...).
Posting the same question over and over again is counter-productive. All you achieve is that people learn to pay no attention whatsoever to the warning any longer. And when eventually a real problem arises, they are going to ignore it because they have learned to do exactly that. It is essentially the story of the boy who cried wolf. There is a lot of wisdom in that story...
You missed the point: it is not about trusting the certificate. The problem is, that the certificate does not belong to the server.
Please tell me:
What was the reply of the server administrator, when you told him about this? You are sure, it is o.k. that the server uses the certificate of another server?
The problem is on the server side, and that is where it should be fixed.
There is nothing to be fixed on the client side (except the man page could be more definite about this). The client *may* offer an option to accept foreign certificates from certain servers permanently, but there is no must at all. And it needs some care and user information to not open up a security hole. If anybody has time to implement this, he is welcomed.
Security problems with TLS/SSL do not arise from useless warnings, that train people to ignore them. They arise from people just wanting to get connected, and ignoring the warnings from the beginning. And they arise from people not understanding certificates. So, why did you not tell me from the beginning, what the problem is (a server with a certificate from another server). My assumption: you did not know, what the problem is, and you did not care.
Cheers
Werner
P.S.: And don't tell me about firefox and Co. Faking "SSL-secured" websites is successfull. One reason: browsers make it too easy to click away warnings permanently without investigating the problem.
Q - What was the reply of the server administrator, when you told him about this? You are sure, it is o.k. that the server uses the certificate of another server?
A - They have their answer posted on their website. It basically boils down to "hand us over a sum of money every year and we will fix it for you". Presumably you then get a certificate signed by some commercial company. That is complete overkill for us, we don't need that.
Also, they are not using the certificate of another server. The certificate is simply using a different alias of the same server. You can check that both have the same IP address. This server is hosting many different domains, which are also constantly changing. They have one self-signed certificate for each physical server.
> Also, they are not using the certificate of another server.
> The certificate is simply using a different alias of the same server.
If it is just an "alias", you can use this aslias in the URL to connect to the server and there will be no problem.
But it probably isn't. Looks like buggy virtual hosting. But note: neither the clients nor the protocol have to care abaout virtual hosting. Two different virtual hosts are two different servers. And your server uses the certificate of another server. Note: "server" does not refer to some piece of hardware, but to the service.
> It basically boils down to "hand us over a sum of money every year and we will
> fix it for you".
Yeah. You have the choice:
- free beer, that does not serve you well
- buy (better) beer for money
Your choice:
Developers of free software have to make the free beer taste fine? But I am more of the "freedom, not free beer"-persuasion.
Cheers
Werner