bugdavfs2 - Bugs: bug #54699, SSL client certificate...

 
 

bug #54699: SSL client certificate authentication doesn't work

Submitted by:  None
Submitted on:  Thu 20 Sep 2018 04:36:00 PM UTC  
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Confirmed
Privacy:  Public Assigned to:  Werner Baumann <wbaumann>
Open/Closed:  Closed

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 25 Jan 2019 08:10:25 AM UTC, comment #13: 

I added a warning and a workaround in the davfs2.conf manual. Because this bug can not be fixed by davfs2 but only by the libraries used I will close this bug report.

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Thu 20 Sep 2018 04:43:23 PM UTC, comment #12: 

I have moved this item to the bug tracker.

It is a bug in the neon library (and also a bug in the OpenSSL library). The neon library seems to be currently unmaintained (the last post from Joe Orton is from February 2017). I'll try whether I am able to fix this, but this will take a lot of time because I'm not familiar with OpenSSL and GruTLS. Maybe somebody else is?

Meanwhile the workaround seems to be to store the certificate chain on the server side or to avoid intermediate CAs if possible.

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Thu 20 Sep 2018 04:36:00 PM UTC, comment #11: 

This item has been reassigned from the project davfs2 support tracker to your tracker.

The original report is still available at support #109517

Following are the information included in the original report:

[field #0]                  Item ID: 109517

[field #1]                 Group ID: 10199

[field #2]              Open/Closed: Open

[field #3]                 Severity: 3 - Normal

[field #4]                  Privacy: Public

[field #7]                         : Unknown support Field Display Type

[field #8]                         : Unknown support Field Display Type

[field #9]                 Category: None

[field #10]             Submitted by: None

[field #11]              Assigned to: wbaumann

[field #12]             Submitted on: Mon 18 Jun 2018 02:42:48 PM UTC

[field #13]                  Summary: SSL client certificate authentication doesn't work

[field #14]      Original Submission: Hello,

I'm working with davfs2 v1.5.2 on devuan. I've managed to successfully mount a WebDAV share using password auth, but now I'm trying to mount a WebDAV share that requires an SSL client certificate.

My config file looks like this:

    clientcert cert.pkcs12.p12
    ask_auth        0

When I call

    mount -v -t davfs "https:///dav/" ./share

I get the following

    Could not read status line: SSL error: tlsv1 alert unknown ca

The certificates are not self-signed. The same pkcs12 file works in my browser with the same server.

The apache server log contains the following:

    AH02276: Certificate Verification: Error (20): unable to get local issuer certificate

The strucuture of the PKI is as follows

 ROOT CA
    |
INTERMEDIATE CA
    |
 USER Cert

Which makes me suspect that davfs2 doesn't send the chain along with the certificate.

Any help is appreciated!
Cheers
Marcel

[field #16]               Item Group: None

[field #17]                   Status: Postponed

[field #18]        Component Version: None

[field #19]         Operating System: GNU/Linux

[field #20]          Reproducibility: None

[field #21]               Size (loc): None

[field #22]            Fixed Release: None

[field #23]          Planned Release: None

[field #24]                   Effort: 0.00

[field #28]                 Priority: 5 - Normal

[field #31]         Percent Complete: 0%

[field #33]                  Release: None

[field #36]         Originator Email: marcel.klehr9@kit.edu

[field #58]     Custom Select Box #1: None

[field #59]     Custom Select Box #2: None

[field #60]     Custom Select Box #3: None

[field #61]     Custom Select Box #4: None

[field #62]     Custom Select Box #5: None

[field #63]     Custom Select Box #6: None

[field #64]     Custom Select Box #7: None

[field #65]     Custom Select Box #8: None

[field #66]     Custom Select Box #9: None

[field #67]    Custom Select Box #10: None

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Tue 28 Aug 2018 02:25:07 PM UTC, comment #10: 

Hello all together,

I tested it earlier with

openssl s_server

on the server side and davfs2 as client.
The client definitely only sends its certificate, not the whole chain.

Best regards,
Jens

Anonymous
Mon 27 Aug 2018 01:43:48 PM UTC, comment #9: 

Hello again,

I have to reopen this thread, I'm afraid.
it turns out that I was testing with a client certificate the chain of which was installed on the server anyways, so the server didn't complain about davfs not sending a chain.
However, I checked and can confitrm that my pkcs file contains the chain. The apache is configured to verify the certificate using the root ca only. Using the same certificate works in my windows webdav client, but doesn't work when used with davfs2. The server log shows

  Certificate Verification: Error (20): unable to get local issuer certificate

in this case. Which to me, otgether with the fact that the same scenario works with my windows client, suggests that davfs/neon doesn't send the intermediate certs.

regards,
Marcel

Marcel Klehr <marcelklehr8>
Fri 29 Jun 2018 03:51:56 PM UTC, comment #8: 

So, it turns out the system's ca certs weren't up to date, which is why the server certificate was rejected and the client didn't even bother to send a chain, apparently.

With up to date ca certs everything works like a charm. Thank you for you patience and the work you're doing here!

Cheers :)

Marcel Klehr <marcelklehr8>
Fri 29 Jun 2018 03:50:53 PM UTC, comment #7: 

Could you just for testing configure your server temporarily to always require a client certificate?

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Fri 29 Jun 2018 01:06:27 PM UTC, comment #6: 

> This is confusing:
>"just noticed I can't check the client chain, since the server only requires client authentication per directory"
> But mounting fails and davfs2 only sends two requests for URL "https://<DOMAIN>/dav/". So of this directory does not require a client certificate, why should mounting fail?


To explain further. I only have WebDAV and client certificate authentication enbabled in my Apache config for /dav. Thus the http server doesn't request a client certificate in the initial SSL handshake because it doesn't know if it is necessary, because the handshake takes place before the http headers are being sent. So, once the handshake has been done, with only the server having been authenticated, the client sends the http request, then the server realizes that the directory in question requires SSL client authentication and thus decides to re-negotiate the SSL connection to authenticate the client. This re-negotiation is done via the already encrypted connection, however, afaict, so I can't see what the client sends in tcpdump.

I will try to debug further with your recommendations.

Marcel Klehr <marcelklehr8>
Thu 28 Jun 2018 05:48:30 PM UTC, comment #5: 

This is confusing:
"just noticed I can't check the client chain, since the server only requires client authentication per directory"
But mounting fails and davfs2 only sends two requests for URL "https://<DOMAIN>/dav/". So of this directory does not require a client certificate, why should mounting fail?

The first request send by davfs2 is an OPTIONS request and the second one is PROPFIND. Some servers are configured to not require authentication on OPTIONS requests. But to find out what is going wrong it is important that the servers requests the client certificate on the first request when the connection is established.

Please care for this:

  • OPTIONS and PROPFIND request require a client certificate.
  • Instead of "https://<DOMAIN>/dav/" mount an URL like "https://<DOMAIN>/dav/a/b" where a and b are both directories that require a client certificate.
  • Set log_level of the Apache-modul mod_ssl to level debug. This should  create a lot more debug information from Apache.

Now test:
While running Wireshark try to mount the davfs2 file system. It probably fails. Now you may inspect the traffic logged by Wireshark, the Apache logs and all of the messages from davfs2. You may alternatively send these files to my private email address (werner.baumann@onlinehome.de). These files may include private data.

Additional:
You may als use the same debugging tools while you visit the same URL with your browser. It is important that this URL is the first resource you fetch from the server so that the connection is newly created.

Differences between these two test might show what is going wrong.

Alternative test:
You could configure your server to use the intermediate CA as the CA to check the client certificate. Of courxe you must install this CA-certificate on your server.

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Tue 26 Jun 2018 12:34:57 PM UTC, comment #4: 

I just noticed I can't check the client chain, since the server only requires client authentication per directory and thus forces a re-negotiation, which runs on the already encrypted connection.

However, the apache server logs the following:

Certificate Verification: Error (20): unable to get local issuer certificate

Marcel Klehr <marcelklehr8>
Tue 26 Jun 2018 08:43:31 AM UTC, comment #3: 

The SSL related debug messages probably show mainly information about the server's certificate.

As your PKCS#12-file contains the complete certificate chain it would be interesting to know whether davfs2 (neon) sends the complete chain to the server. This should happen when the TLS-connection is established before the content is encrypted. Could you please use Wireshark to check this?

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Mon 25 Jun 2018 11:11:42 AM UTC, comment #2: 

Thanks for the reply!

I tried debug mode, but only got lots of lines containing what I presume to be the certificate data, plus a few instances of the following for all certs in the chain:

    Jun 25 12:52:16 xxx mount.davfs: ssl: Match common name 'Deutsche Telekom Root CA 2' against ''
    Jun 25 12:52:16 xxx mount.davfs: Identity match for '': bad

I checked the pkcs file with openssl as you suggested and it seems to contain all intermediate certs including the root cert.

I'm testing davfs on the same system that runs the WebDAV server, btw. Not sure if that makes a difference.

Marcel Klehr <marcelklehr8>
Wed 20 Jun 2018 04:39:08 PM UTC, comment #1: 

davfs2 uses the Neon library for all HTTP- and HTTPs-requests and Neon uses either OpenSSL or GnuTLS for TLS-connections.

As far as I understand the TLS-specification the client (davfs2) is responsible for providing the full certificate chain (except the root certificate). But I am not sure which component of the client is responsible. It could be

  • the PKCS#12 file
  • davfs2
  • neon (using the system's certificate store)
  • the ssl-library (using the system's certificate store)

(The browser may treat this not the same way as Neon does).

Concerning what davfs2 (my code) could do: davfs2 is restricted to what the interface of Neon provides. This are functions to read the client certificate from the PKCS#12-file or a buffer, functions to decrypt the private key, some functions to show information from the certificate and functions to add the client certificate to the session object. There are no functions to deal with intermediate CAs.

What I suggest to do next:

  • You may set option "debug ssl". This might show some additional information in one of your log files (look for messages from mount.davfs).
  • Please use the openssl tool with command pkcs12 to check wether  the intermediate CA-cert is contained in your file. If not, the same tool allows you to add the missing certificate to the file (you surely created a copy before manipulating your p12-file).
  • You may check whether the intermediate CA-cert is present in your system's certificate store (/etc/ssl/certs/) so that OpenSSL can get it from there.

I think that having the complete certificate chain in the PKCS#12-file should make sure that it is working. If not, it might be a bug in Neon (I believe that client certificates are not used very much and bugs might survive for quite a long time).

Werner

Werner Baumann <wbaumann>
Project AdministratorIn charge of this item.
Thu 20 Sep 2018 04:36:00 PM UTC, original submission:  

Hello,

I'm working with davfs2 v1.5.2 on devuan. I've managed to successfully mount a WebDAV share using password auth, but now I'm trying to mount a WebDAV share that requires an SSL client certificate.

My config file looks like this:

    clientcert cert.pkcs12.p12
    ask_auth        0

When I call

    mount -v -t davfs "https://<DOMAIN>/dav/" ./share

I get the following

    Could not read status line: SSL error: tlsv1 alert unknown ca

The certificates are not self-signed. The same pkcs12 file works in my browser with the same server.

The apache server log contains the following:

    AH02276: Certificate Verification: Error (20): unable to get local issuer certificate

The strucuture of the PKI is as follows

 ROOT CA
    |
INTERMEDIATE CA
    |
 USER Cert

Which makes me suspect that davfs2 doesn't send the chain along with the certificate.

Any help is appreciated!
Cheers
Marcel

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by marcelklehr8 (Posted a comment)
  • -email is unavailable- added by wbaumann (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-25 wbaumann StatusPostponed => Confirmed
        Open/ClosedOpen => Closed
    2018-09-20 wbaumann StatusNone => Postponed
        Assigned toNone => wbaumann
    2018-09-20 wbaumann Reassign itemdavfs2, sr #109517 => davfs2, bug #54699

    Back to the top


    Powered by Savane 3.7