Verwendet man WebDAV-Freigaben mit einer sicheren Verbindung unter Linux (gvfs) wird immer ein Zertifikatsfehler angezeigt, wenn man Let’s Encrypt als Zertifizierungsstelle verwendet. Durch manuellen Import der Zertifikate lässt sich das beheben.
Let’s Encrypt ist eine der größten Erfolge für die Sicherheit des Internets in den vergangenen Jahren. Im Gegensatz zu vielen anderen Vorhaben geschah diese auch endlich mal wieder durch die Gemeinschaft und nicht unter der Ägide eines der großen IT-Giganten. Mittels Let’s Encrypt sind verschlüsselte Verbindungen Standard geworden und die kommerziellen Zertifizerungsstellen wurden massiv zurückgedrängt.
WebDAV ist wiederum der Standard für Dateifreigaben im Internet, analog zu CalDAV für Kalendereinträge und CardDAV für Adressbücher. Viele proprietäre Dienste, aber auch solche wie das Open Source Flaggschiff Nextcloud setzen auf WebDAV.
Ausgerechnet diese beiden Dienste vertragen sich unter Linux nicht besonders gut. Versucht man bei einem Desktop, der auf GVFS basiert (GNOME Virtual File System) eine WebDAV-Freigabe mit HTTPS-Verbindung einzurichten, scheitert man mit einer kryptischen Fehlermeldung. Erschreckend vor allem, weil das Problem schon seit 2015 besteht, wie es Chris bei LinuxuUndIch damals beschrieb. Ich möchte das hier aufgreifen, weil einige Lösungsschritte von damals nicht mehr aktuell sind.
Das Problem ist relativ leicht erklärt. Zwar „vertrauen“ alle großen Browser den Let’s Encrypt-Stammzertifikaten, aber die Distributionen haben diese in ihre Systemzertifikate aus irgendwelchen Gründen immer noch nicht aufgenommen. Ob man davon betroffen ist, kann man auf der Konsole überprüfen, indem man dort die WebDAV-Freigabe einbindet. Wie immer sind die konkreten Angaben natürlich anzupassen.
$ gio mount davs://domain.de:0000/cloud
Code-Sprache: JavaScript (javascript)
Erhält man dort eine Fehlermeldung mit einem ungültigen Zertifikat, ist man davon betroffen.
Die Lösung besteht darin, die Stammzertifikate manuell zu installieren. Diese kann man auf der Seite von Let’s Encrypt beziehen. Hier muss man verschiedene Zertifikate einspielen. Man benötigt die Root-Zertifikate und die Intermediate-Zertifikate, da bei mir z. B. alle Zertifikate mittelbar durch Let’s Encrypt R3 ausgestellt wurden.
$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-r3.pem
Code-Sprache: JavaScript (javascript)
Diese Zertifikate muss man anschließend mit Root-Rechten einspielen.
# trust anchor lets-encrypt-x1-cross-signed.pem
# trust anchor lets-encrypt-x2-cross-signed.pem
# trust anchor lets-encrypt-r3.pem
Code-Sprache: CSS (css)
Abschließend kann man prüfen, ob alles ordnungsgemäß eingespielt wurden. Bei den Root Zertifikaten:
$ trust list | grep -C 2 "Let's Encrypt"
pkcs11:id=%A8%4A%6A%63%04%7D%DD%BA%E6%D1%39%B7%A6%45%65%EF%F3%A8%EC%A1;type=cert
type: certificate
label: Let's Encrypt Authority X1
trust: anchor
category: authority
--
pkcs11:id=%C5%B1%AB%4E%4C%B1%CD%64%30%93%7E%C1%84%99%05%AB%E6%03%E2%25;type=cert
type: certificate
label: Let's Encrypt Authority X2
trust: anchor
category: authority
Code-Sprache: PHP (php)
Und beim Intermediate-Zertifikat:
$ trust list | grep -C 2 "R3"
pkcs11:id=%14%2E%B3%17%B7%58%56%CB%AE%50%09%40%E6%1F%AF%9D%8B%14%C2%C6;type=cert
type: certificate
label: R3
trust: anchor
category: authority
Code-Sprache: PHP (php)
Bei Letzterem werden ggf. noch weitere Zertifikate gefunden. Hier muss man dann genau hinschauen.
Die abschließende Prüfung ist natürlich die WebDAV-Freigabe. Gibt es keine Fehlermeldung bei der Einbindung, ist alles glattgegangen.