Die von Let’s Encrypt kostenlos angebotenen Zertifikate zum Verschlüsseln von Internetverbindungen machen seit dem Start der öffentlichen Beta-Phase kräftig Wind. Kaum ein IT-Magazin oder Blog ignoriert das Thema, von Fefe kommt selbstverständlich eine ordentliche Breitseite und selbst altehrwürdige Einrichtungen des Blätterwalds wie die Zeit widmen dem Thema lange Artikel. Ich persönliche teste Let’s Encrypt zum Beispiel aktuell auf einem NAS-Gerät von Synology, so muss ich mich nicht mehr mit selbst-signierten Zertifikaten plagen — auch wenn ein Mechanismus zum automatischen Aktualisieren des Let’s-Encrypt-Zertifikats noch fehlt. Die Installation eines Let’s-Encrypt-Zertrifikat auf einem Synology-NAS hatte ich erst kürzlich hier im Blog beschrieben.
In der Praxis fällt mir nun auf, dass die Let’s-Encrypt-Zertifikate zwar von den gängigen Browsern wie Chrome oder Firefox akzeptiert werden, das System selbst kommt mit den Zertifikaten jedoch noch nicht zurecht, da dieses das Let’s-Encrypt-Stammzertifikat in der Regel noch nicht kennt. Dies spürt man beispielsweise bei verschlüsselten WebDAV-Verbindungen, die man über den Dateimanager aufbauen möchte. Unter Gnome meldet Files (aka Nautilus) etwa recht wortkarg „Unbekannte Fehlermeldung: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat“. Aufgrund eines uralten Bugs aus dem Jahr 2007 geht es danach auch nicht mehr weiter. Mit einem aktuellen Gnome-System lässt sich ein WebDAV-Share nicht verschlüsselt einbinden, egal ob Let’s Encrypt oder ein selbst-signiertes Zertifikat.
Das Geschehen kann man auch recht schön auf der Kommandozeile nachvollziehen: Nautilus macht nichts anderes als die WebDAV-Freigabe über das Gnome Virtual File System (aka GVFS) einzubinden, das entsprechende Kommando dafür lautet schlicht gvfs-mount
gefolgt von der URL des entsprechenden Dienstes. Auch hier ist das Ergebnis wieder, dass GVFS den Verbindungsaufbau trotz explizierter Anweisung verweigert. Dasselbe würde übrigens auch mit einem selbst-signierten Zertifikat passieren, es sind also nicht nur Anwender von Let’s Encrypt von diesem Problem betroffen.
$ gvfs-mount davs://home.example.com:5006 Die Identität der Gegenseite kann nicht bestätigt werden: Die Zertifikats-Ausgabestelle ist unbekannt Certificate information: Identity: home.example.com Verified by: Let's Encrypt Authority X1 Expires: 02.03.2016 Fingerprint (SHA1): 93 AD D4 91 ED 57 93 BF 53 D9 4D C2 4D D5 2D 39 1D 83 9C 95 Sind Sie absolut sicher, dass Sie fortsetzen wollen? [1] Ja [2] Nein Choice: j Fehler beim Einhängen des Ortes: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat
Möchtet ihr nun nicht darauf verzichten euer NAS per verschlüsseltem WebDAV einzubinden, müsst ihr die Let’s-Encrypt-Stammzertifikate in eurem System installieren. Ihr könnt das jetzt manuell machen, oder ihr wartet bis der Distributor eurer Linux-Installation dies für euch erledigt — was je nach Distribution ein ganzes Weilchen brauchen kann. Mit den folgenden Kommandos ladet ihr die Let’s-Encrypt-Stammzertifikate aus dem Netz und installiert diese im System. Ein selbst-erstelltes Zertifikat ließe sich auf dem selben Weg einspielen, gebt bei Bedarf einfach den vollständigen Pfad zur Datei an.
$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem $ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem $ sudo trust anchor lets-encrypt-x1-cross-signed.pem $ sudo trust anchor lets-encrypt-x2-cross-signed.pem
Zur Kontrolle könnt ihr euch danach mit trust list
die im System verfügbaren Zertifikate ausgeben lassen. Mit ein bisschen Grep-Magie sollte das Kommando dann nur die zwei neuen Let’s-Encrypt-Zertifikate ausspucken — wenn nicht, dann hat irgendwas mit der Installation der Zertifikate nicht funktioniert. Anschließend öffnet ihr wieder Nautilus und gebt abermals davs://home.example.com:port als URL in die Adresszeile ein. Diesmal sollte der Dateimanager das Zertifikat anstandslos akzeptieren und die verschlüsselte Verbindung zum NAS anstandslos aufbauen. Was ich hier mit Nautilus unter Gnome mache, sollte eigentlich auch mit den Dateimanagern anderer Desktopumgebungen funktionieren, also etwa bei KDE und Dolphin.
$ 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
Solltet ihr die Stammzertifikate (oder ein entsprechend selbst-signiertes) später einmal wieder vom System löschen wollen, dann hängt an das Kommando trust anchor
einfach noch ein --remove
mit dem Pfad zur Zertifikat-Datei oder der entsprechenden PKCS-Kennung an. Achtet dabei bitte darauf kein wirklich wichtiges Zertifikat zu löschen, sonst weigert sich beispielsweise die Paketverwaltung mit den Paketquellen zu sprechen oder es lassen sich viele verschlüsselte Webseiten nicht mehr öffnen.
$ trust anchor --remove /pfad/zu/zertifikat.crt $ trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;object-type=cert"
Kurze Anmerkung: Ich erhalte auf Ubuntu 14.04 beim trust anchor Befehl:
+1
Kann das Problem mit einem frisch installierten Ubuntu 14.04 nachvollziehen, das Kommando
trust anchor
liefert immer die besagte Fehlermeldung. Allerdings scheint die Zertifikat-Datenbank mittlerweile aktuell zu sein. Nach Einspielen aller Updates, kann ich mich ohne Zertifikat-Warnung per WebDAVs verbinden. Grüße, Christoph.+1
Es funktioniert auch anders. Habe es nach dieser Anleitung: https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu
hinbekommen.