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