Webdav stopped trusting server certificate, curl seems to continue to trust

Since a couple of days, I mount my NextCloud share, hosted by a NextCloud provider, with webdav.
Since today, webdav no longer trusts the server certificate and I have to confirm the fingerprint.
What could I have (unknowingly) changed?

I read the FAQ, searched, found and read Certificate is not trusted in terminal but works in firefox
But different from that case, I have not installed a server certificate on the client.

My (rented) domain is:


I use this host:
A headless Raspberry Pi

uname -a
Linux zeroW 5.15.61+ #1579 Fri Aug 26 11:08:59 BST 2022 armv6l GNU/Linux

I ran this command:

mount /mnt/dav

Where /etc/fstab contains

https://km-wolke.de/remote.php/webdav/ /mnt/dav davfs _netdev,noauto,user,uid=markus,gid=markus 0 0

It produced this output:

/sbin/mount.davfs: the server certificate is not trusted
  issuer:      Let's Encrypt, US
  subject:     km-wolke.de
  identity:    km-wolke.de
  fingerprint: (((snip)))  (((is it save to share a fingerprint?)))
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]

My web server is (include version):

No web server on my host

The operating system my web server runs on is (include version):

I don't know

My hosting provider, if applicable, is:


I can login to a root shell on my machine (yes or no, or I don't know):

On the client yes, on the server no

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):


The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

No certbot

I ran this command:

curl -v https://km-wolke.de/remote.php/webdav/

It produced this output (which says the certificate is OK?):

*   Trying 2a00:17d8:200::2b1:443...
* Connected to km-wolke.de (2a00:17d8:200::2b1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=km-wolke.de
*  start date: Aug 14 06:24:29 2022 GMT
*  expire date: Nov 12 06:24:28 2022 GMT
*  subjectAltName: host "km-wolke.de" matched cert's "km-wolke.de"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x646b40)
> GET /remote.php/webdav/ HTTP/2
> Host: km-wolke.de
> user-agent: curl/7.74.0
> accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 401 
< server: nginx
< date: Sun, 25 Sep 2022 12:03:49 GMT
< content-type: application/xml; charset=utf-8
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< set-cookie: oc_sessionPassphrase=p%2FJdR9x3BIVukG6rquLALpl0Wi8dsQ%2BLc8aXKO896gwiv4hiuBdwMMGTXlaSgti%2FEKbj21y5u1au4MIWWGTaf2m5MsSn%2BFb4kvGMIOZ0FZJt0XwwZy%2FR0tJQSvfRI3%2BW; path=/; secure; HttpOnly; SameSite=Lax
< set-cookie: ocslt7sf5faa=d57e504b169d109d64d828644b4951d3; path=/; secure; HttpOnly; SameSite=Lax
< set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< content-security-policy: default-src 'none';
< www-authenticate: Basic realm="Managed Nextcloud", charset="UTF-8"
< strict-transport-security: max-age=15768000; includeSubDomains;
< referrer-policy: no-referrer
< x-content-type-options: nosniff
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: none
< x-xss-protection: 1; mode=block
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:message>No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured</s:message>
* Connection #0 to host km-wolke.de left intact

Welcome to the community @markusLE

I don't know webdav but all certificates are logged publicly. Several tools exist to view these logs. You can see your most recent Leaf cert here and its fingerprint. If that's your expected cert you can probably trust it.

I cannot speak to why webdav would issue that message. Someone else here might.

Let's Encrypt certs are usually renewed every 60 days. Could this message just be warning of using a newer cert than earlier?


Thank you, @MikeMcQ
I am very impressed, this is indeed the fingerprint, so a fingerprint is public information.

Where did you get 7333253477 from?
I cannot find it.

curl -v reports the certificate is valid

*  start date: Aug 14 06:24:29 2022 GMT
*  expire date: Nov 12 06:24:28 2022 GMT

And I used webdav only in starting in September, so it was never in touch with the previous 60-day version.


From: https://crt.sh/

Enter your domain name for your history. Each cert has a Pre-cert and a Leaf. The Leaf is the one to use. There is sometimes as much as a 24H delay before a new cert appears in crt.sh (for future reference)


Thank you,
found it, understood. Cool!

As curl and a browser are happy with the certificate, it seems like the problem lies within webdav.


DavFS2 seems to be using the library "Neon" which in turn seems to be relying on OpenSSL or GnuTLS for the certificate (chain) verification.

Your server is sending the "long, Android-pre-7-compatible" certificate chain, which can interfer with proper verification of the chain in certain versions of OpenSSL (1.0.2 I believe). Not sure how GnuTLS handles the long chain though.

If you don't have any interest in Android versions pre-7 visiting your website, you could consider switching to the alternative "short" chain.

Although I read just now from your OP that your WebDAV is hosted by some Nextcloud provider? Is that webserver under your controle to begin with? I.e., root access and all?


Hi Osiris, I have (and want) no control over the server.
I can only write email to the NextCloud provider.

In that case, you might want to concentrate on your RPi to fix this. However, the neon documentation is quite sparse so I have no idea how to debug if neon is the issue here or not unfortunately.

You might want to consider checking with a Nextcloud instance offering the short chain if that works with davfs in the first place before going down a bughunt hole or email your Nextcloud provider. That said, no clue if there are Nextcloud test environments laying around the internet also magically serving the short chain :roll_eyes:


Thank you, Osiris,
I will consider my options.


I noted my raspberry pi client only had one CA-certificate (in /etc/ssl/certs/)

I added CA-certificates using the commands
NextClould uses ISRG Root X1, I added all

sudo apt install ca-certificates
sudo dpkg-reconfigure ca-certificates

This resolved the issue.

Now mounting works again without a query

$ umount /mnt/dav
/sbin/umount.davfs: waiting for mount.davfs (pid 11034) to terminate gracefully .. OK
$ mount /mnt/dav

I assume the CA-certificates were present earlier and it's unclear how or why I deleted them.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.