maindavfs2 - Support: sr #109658, SSL not working

 
 

sr #109658: SSL not working

Submitter:  None
Submitted:  Mon 18 Mar 2019 09:27:24 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Confirmed
Privacy:  Public Assigned to:  _71007
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 22 Mar 2019 07:01:40 PM UTC, comment #1: 

That empty server name is related to the details of how Neon and OpenSSL check the certificate. Maybe it is just an error in how the debug message is created. It also appears when verification is successful and it is not the reason of the problem. The real problem is the message "ssl: Unhandled verification error 67 -> CA certificate key too weak".

To better understand the problem (and why I can't resolve it) some information about how option trust_server_cert works.

With this option set there is still

  • Step 1: Neon and the SSL-library try to verify the certificate submitted by the server. Because davfs2 did not allow to trust the systems default CA-certificates this verification must fail.
  • Step 2: After verification failed Neon will hand the server certifacate over to davfs2 (using a callback function). davfs2 will compare this certificate to the one you gave with option trust_srver_cert. If they are identical the connection will be established.


As you may notice step 1 is completely useless and I would like to avoid it. But I could not find anything in the Neon interface that would allow for this. But what really annoys is this:
Neon will only hand over the certificate to davfs2 when verfication fails with a kind of error that Neon thinks can be handled by the application or the user. When verification fails because ther is no trusted CA-certificate it will work fine. For other error codes it will return an error and davfs2 has no chance to allow the connection.

This is what happens in your case: Neon thinks that error 67 can't be handled by davfs2 or you.

Of course this should not happen. As long as the certificate provided by the server matches the configured one, the connection should be established. But I have no idea how to change this (except not using the neon library).

Maybe the server can use another certificate. Probably the CA that created this cert really has a weak key and should change this anyway.

Werner

- <_71007>
Mon 18 Mar 2019 09:27:24 AM UTC, original submission:  

I downloaded the certificate for the server (dms.office.noris.de" with firefox and then attempted to connect to it with "trust_server_cert" set.

Mär 18 10:23:46 miner mount.davfs[32872]: davfs2 1.5.5
Mär 18 10:23:46 miner mount.davfs[32872]: Initializing webdav
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: SNI enabled by default.
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: Match common name '*.office.noris.de' against ''
Mär 18 10:23:46 miner mount.davfs[32872]: Identity match for '': bad
Mär 18 10:23:46 miner mount.davfs[32872]: Doing SSL negotiation.
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: Verify callback @ 1 => 19
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: Verify failures |= 8 => 8
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: Verify callback @ 1 => 67
Mär 18 10:23:46 miner mount.davfs[32872]: ssl: Unhandled verification error 67 -> CA certificate key too weak

Where is that empty server name coming from?

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 _71007 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-22 _71007 StatusNone Confirmed
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.14-f13d.
    Corresponding source code