Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

davfs does not trust self-signed certificate

Help
pvh513
2008-03-11
2013-04-16
  • pvh513
    pvh513
    2008-03-11

    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.

     
    • Werner Baumann
      Werner Baumann
      2008-03-13

      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

       
    • pvh513
      pvh513
      2008-03-18

      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

       
    • Werner Baumann
      Werner Baumann
      2008-03-18

      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

       
    • pvh513
      pvh513
      2008-03-18

      "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!

       
    • Werner Baumann
      Werner Baumann
      2008-03-18

      > 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

       
    • Werner Baumann
      Werner Baumann
      2008-03-18

      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

       
    • pvh513
      pvh513
      2008-03-19

      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...

       
    • Werner Baumann
      Werner Baumann
      2008-03-19

      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.

       
    • pvh513
      pvh513
      2008-03-28

      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.

       
    • Werner Baumann
      Werner Baumann
      2008-03-29

      > 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