Synology DSM 6.0 unterstützt Let’s Encrypt

Nun lässt sich Synology wohl nicht lange bitten und rollt Let’s Encrypt in der kommenden Version der DSM-Software aus. Mit der aktuell vorliegenden Version DSM 6.0 Beta 2 des Betriebssystems lässt sich das Ganze bereits testen — bis zum endgültigen Release wird sich an dieser Stelle wohl auch nicht mehr viel ändern. Wer nun Let’s Encrypt zusammen mit seiner Diskstation nutzen möchte, der muss den Port 80 von seinem Router auf die Diskstation weiterleiten. Auf einer Fritzbox etwa könnt ihr diese Portweiterleitung unter Internet | Freigaben | Portfreigaben einrichten. Ihr braucht Port 80/TCP (http) für den Let’s Encrypt-Client und für später dann selbstverständlich auch Port 443/TCP (https) für die verschlüsselten Daten.

Danach öffnet ihr das Webfrontend eures Synology-Systems und geht in die Systemsteuerung. Dort wählt ihr dann Sicherheit | Zertifikate an. Die Liste ist selbstverständlich anfangs noch leer, mit einem Klick auf Hinzufügen startet ihr hier das Erzeugen eures Let’s Encrpyt-Zertifikats. Der Assistent fragt euch im ersten Schritt ob ihr ein Neues Zertifikat hinzufügen möchtet oder ob ihr ein Vorhandenes Zertifikat ersetzen möchtet — in meinem Fall gab es bereits eines, im Endeffekt unterscheidet sich das weitere Vorgehen jedoch nicht.

Let’s Encrpyt auf Synology einrichten

Der mit DSM 6.0 überarbeitete Zertifikats-Assistent bietet euch nun den Punkt Zertifikat von Let’s Encrypt abrufen. Dieser Menüpunkt startet nun, genauso wie auf einem „richtigen“ Webserver, den Let’s Encrpyt-Client. Dieser erzeugt die Schlüsselt, authentifiziert euch automatisch gegenüber Let’s Encrpyt und spielt dann abschließend die erhaltenen Zertifikate in das System ein. Mehr als ein paar Klicks braucht die Installation der Let’s Encrpyt-Zertifikate daher also nicht mehr. Das umständlich Basteln und hier und her Schieben der Daten fällt komplett weg.

Am Ende sollte euer Browser mit einem grünen Schloss-Symbol in der Adresszeile signalisieren, dass mit der Verschlüsselung eures Synology-NAS alles stimmt. Das Zertifikat kommt nun automatisch nicht nur beim Aufruf der Weboberfläche zum Einsatz, sondern unter anderem auch bei FTP- oder WebDAV-Verbindung. So könnt ihr super einfach von unterwegs — die meisten Dateimanager unter Linux unterstützen ja Verbindungen zu entfernten Systemen — auf die Daten eures NAS-Systems zugreifen. Damit dies allerdings ohne Warnungen funktioniert, müsst ihr wahrscheinlich noch das Stammzertifikat von Let’s Encrypt auf eurem Linux-System installieren.

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"

UPDATE 22.01.2016: Dieser Artikel ist inzwischen veraltet, da Synology DSM 6.0 das Einbinden und Aktualisieren von Lets’s Encrypt-Zertifikaten out-of-the-box unterstützt. Wer eine halbwegs aktuelle Diskstation besitzt, sollte daher besser das System auf einen aktuellen Stand bringen, sodass DSM 6.0 läuft und sich dann an diese Anleitung halten: Mit DSM 6.0 Let’s Encrypt-Zertifikate auf Synology-NAS einrichten.

Zum Erzeugen des Let’s-Encrpyt-Zertifikat holt ich euch den vom Projekt bereitgestellten Client auf den Rechner. Unter Arch Linux bekommt ihr das Programm schon aus den offiziellen Paketquellen, für Ubuntu hat zum Beispiel Thomas Leister bereits eine kleine Installationsanleitung geschrieben. Der Client fungiert als Schnittstelle zwischen eurem System und den Servern des Projekts. Er kann auch Zertifikate direkt im System installieren und in Apache einbinden. Für das Erstellen eines Zertifikats, das später einmal auf einem NAS landen soll, braucht man diese Funktionen allerdings gar nicht.

$ pacman -Ss letsencrypt
community/letsencrypt 0.1.0-1 [Installiert: 0.0.0.dev20151201-1]
    A tool to automatically receive and install X.509 certificates to enable TLS
    on servers. The client will interoperate with the Let’s Encrypt CA which
    will be issuing browser-trusted certificates for free.
community/letsencrypt-apache 0.1.0-1
    Apache plugin for Let’s Encrypt client
community/letsencrypt-nginx 0.1.0-1
    Nginx plugin for Let’s Encrypt client
community/letshelp-letsencrypt 0.1.0-1
    Let's help Let's Encrypt client
$ sudo pacman -S letsencrypt

Anschließend ruft ihr den Let’s-Encrpyt-Client mit Root-Rechten auf. Die Option certonly -a manual sorgt dabei dafür, dass der Client das Zertifikat nur erzeugt, aber nicht auch noch zu installieren versucht. In der Beta-Version musste man zudem noch mit etwa --server https://acme-v01.api.letsencrypt.org/directory der Server angeben, mit der heute veröffentlichten Version 0.1.0 des Clients ist diese Option nun nicht mehr nötig. Verzichtet ihr auf die Angabe einer Domain und einer E-Mail-Adresse wird euch das Programm nach diesen Angaben fragen, alternativ gibt ihr diese Infos dem Client gleich mit auf dem Weg.

### Ohne Optionen, Abfragen erfolgen in einer Ncurses-Oberfläche
$ sudo letsencrypt certonly -a manual
### Direkt mit allen Angaben
$ sudo letsencrypt certonly -a manual --email du@email.de -d domain.example.com

Voraussetzung für diese Aktion ist natürlich, dass euer NAS über HTTP und HTTPS aus dem Netz zu erreichen ist und dass ihr eine DynDNS-Adresse besitzt, unter der euer Netzwerkspeicher aus dem Internet zu erreichen ist. Eine Synology erfüllt diese Kriterien, wenn ihr unter Systemsteuerung | Externer Zugriff | DDNS ein entsprechendes Konto eines DynDNS-Anbieters einträgt (alternativ können diese Aufgabe aber auch Router wie eine Fritz!Box übernehmen und unter Systemsteuerung | Webdienste die Web Station als Dienst aktiviert und weiter unter die Option HTTPS-Verbindungen für Webdienste aktivieren setzt. Beachtet bitte auch, dass ihr mindestens die Ports 80 (für HTTP) und 443 (für HTTPS) von eurem Router auf das NAS weiterleitet müsst.

Weiter geht es mit der Zertifikat: Der Let’s-Encrpyt-Client versucht nun die angegebene Domain zu erreichen und zeigt euch bei Erfolg eine Adresse wie „http://domain.example.com/.well-known/acme-challenge/hierkommteinzufälligercode“ mitsamt einem langen kryptischen Code an. Diese URL mitsamt der damit verbundenen Datei dient zur Identifikation eures Webservers. Die Installations-Skripte des Clients könnten euch diese Aufgabe nun abnehmen, allerdings kann der Client mit eurem NAS-System nun natürlich weniger anfangen, daher müsst ihr diese Datei von Hand auf dem Webserver des NAS-Systems anlegen.

Loggt euch also beispielsweise per Samba auf eurem NAS ein, wechselt in das Verzeichnis mit den Webdaten, erzeugt die Ordnerstruktur .well-known/acme-challenge (ja, der Punkt gehört da hin) und in diesem dann die Datei hierkommteinzufälligercode mitsamt dem länglichen String, den euch der Client ausgibt. Das ganze funktioniert natürlich in der Regel auch über die Weboberfläche des NAS-Systems. Zur Kontrolle könnt ihr danach einfach mal auf den Link klicken und ihn in einem Browser auf eurem Rechner öffnen. Dazu muss natürlich die Namensauflösung der Internetdomain auch aus eurem lokalen Netzwerk heraus funktionieren. Zeigt dieser den Inhalt der Datei an, dann sollte alles funktionieren.

Make sure your web server displays the following content at
http://domain.example.com/.well-known/acme-challenge/hierkommteinzufälligercode before continuing:

o6klFxce...diesercodedientzumidentifiziereneuresnas

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
printf "%s" o6klFxce...diesercodedientzumidentifiziereneuresnas > .well-known/acme-challenge/o6klFxcezfKWMClYLxIw_HDJ1uPo268aZrtiaUpOtjg
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue

Liegt die Datei auf dem Webserver und habt ihr die Erreichbarkeit über den Browser geprüft, dann geht mit der Eingabe von [Enter] einen Schritt weiter. Die Let’s-Encrypt-Server rufen die Authentifizierungsdatei von eurem Webserver ab, kontrollieren sie auf Gültigkeit und stellen dann das für die angegebene Domain für 90 Tage gültige Zertifikat aus. Dieser landet dann automatisch unter /etc/letsencrypt/live/domain.example.com auf eurer Festplatte. Die begrenzte Gültigkeit begründet Let’s Encrypt mit erhöhter Sicherheit, da so verloren gegangene oder missbrauchte Zertifikate relativ schnell ihre Gültigkeit verlieren. Das Ziel sei es sowieso das Generieren der Zertifikate zu automatisieren, dann soll die Zeitspanne sogar noch weiter sinken.

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/domain.example.com/fullchain.pem. Your cert
will expire on 2016-03-02. To obtain a new version of the
certificate in the future, simply run Let's Encrypt again.

Für die Installation der Zertifikate auf einem Synology-NAS müsst ihr euch nun wieder in die Weboberfläche eures Netzwerkspeichers einloggen und (im Falle eines Synology-Systems) nach Systemsteuerung | Sicherheit | Zertifikat gehen. Dort wählt ihr die Option Zertifikat importieren und gebt die privkey.pem als privaten Schlüssel und die fullchain.pem als Zertifikat an. Damit ihr an diese Dateien kommt, müsst ihr sie allerdings erst einmal aus dem Ordner mit Root-Rechten rauskopieren, da nur Root Zugriff auf diese Dateien hat und somit der Browser fehlende Rechte moniert. Ein Weg dies zu tun, wäre beispielsweise der Folgende, natürlich führen hier zahlreiche andere Wege zum selben Ziel.

$ sudo -s
# cd /etc/letsencrypt/live/domain.example.com/
# ls
cert.pem chain.pem fullchain.pem privkey.pem
# cp fullchain.pem privkey.pem /tmp
# exit
$ sudo chown $USER /tmp/*.pem

Am Ende meldet die Zertifikats-Verwaltung des Synology-NAS nun ein von der „Let’s Encrypt Authority X1“ signiertes SSL-Zertifikat. Die Gültigkeit beträgt wie gesagt 90 Tage, ihr solltet das Zertifikat vor Ablauf dieser Zeitspanne erneuern, wiederholt dazu einfache alle hier gezeigten Schritte. Aktuell führt daran kein Weg vorbei, hier müssen Synology und Co. aktiv werden und eine Funktion direkt in die Software der NAS-Geräte implementieren, über die sich Let’s-Encrypt-Zertifikate direkt aus dem System heraus erzeugen und Verwalten lassen. Die wird mit Sicherheit kommen. Ich hoffe, dass die Hersteller dabei aber auch ältere Geräte nicht außen vor lassen. Noch ein Hinweis am Rande: Meldet das System ein von „Happy Hacker Fake CA“ ausgestelltes Zertifikat, dann seid ihr noch mit einem Beta-Client unterwegs.

Am Ende muss auch noch der von euch genutzte Browser das Zertifikat akzeptieren. Das wäre zum Testzeitpunkt mit Chrome 47.0 wie auch mit Chromium 47.0 der Fall. Beide Browser signalisieren über ein grünes „https://“ in der Adresszeile, dass mit dem Zertifikat alles stimmt. Firefox 42.0 hingegen und beispielsweise der in Gnome integrierte Browser stoßen sich jedoch weiterhin am Aussteller des Zertifikats und melden „This Connection is Untrusted“. Ironischerweise muss als noch Mozilla als einer der wichtigsten Platinum-Sponsoren seine Hausaufgaben machen, was allerdings mit Sicherheit bald geschehen wird.