Vorgeschichte
Auf meinem Heimserver läuft owncloud, nein nicht nextcloud, sondern das Debian-Paket. Konkret läuft das in einer virtuellen Maschine (troubadix) auf einem lighttpd. Ganz grob hatte ich das schonmal in owncloud mit lighttpd auf Debian Jessie beschrieben. An die VM komm ich aber nicht von außen ran, wenn ich das will, muss ich über den Reverse Proxy (nginx), der auf einer anderen VM (susan) läuft. Da mobile Geräte intern wie extern über die gleiche Adresse zugreifen sollen, gibt es dafür die Adresse owncloud.home.example.com und von extern landet man damit über die externe IPv4 und Port Forwarding im Router auf dem Reverse Proxy. Mein interner DNS löst die selbe Adresse als Alias bzw. cname direkt auf die VM mit der owncloud Instanz auf. Zugriffe sollen alle verschlüsselt ablaufen, zuvor sorgte ein von Hand installiertes Zertifikat von CAcert dafür. Der aufmerksame Leser wird sich denken können: dieses musste einmal im lighttpd (troubadix) und einmal im nginx (susan) installiert werden.
Das funktionierte alles soweit, bis das Zertifikat abgelaufen war. Aus diversen Gründen sollte das neue Zertifikat von letsencrypt kommen.
Zertifikate von letsencrypt
Was letsencrypt ist oder macht, die Erklärung spar ich mir an dieser Stelle. Fakt ist, dass es Alternativen zum offiziellen sogenannten certbot gibt und nicht zu knapp: ACME Client Implementations. Ich hatte mir kurz certbot und dehydrated angesehen, einige der gelisteten Implementierungen wird es ab Debian 9 (Stretch) auch direkt als Debian-Paket geben. Zum Einsatz kommt bei mir jetzt aber acme.sh, da ich es schnell verstanden habe und zügig einrichten konnte, naja fast. Ein bisschen tricky war es die webroot-Methode so einzurichten, dass auf der eigentlich voll verschlüsselten Domain das acme challenge Verfahren unverschlüsselt ablaufen kann.
acme.sh
Zur Installation von acme.sh hab ich als normaler User (alex) das GitHub-Repository geklont und etwas widerwillig mit ./acme.sh --install --accountemail post@lespocky.de installiert. Der Empfehlung das als root zu machen, würde ich nicht folgen. Eher legt man sich dafür noch einen extra User an, ich hab hier meinen normalen User benutzt, was aus security-Sicht auch nicht zu empfehlen ist. ;-) Letztlich braucht dieser Nutzer nur Schreibrechte in seinem eigenen $HOME und in einem Ordner, den der Webserver als webroot ausliefern kann.
Blöd: acme.sh hängt ungefragt folgende Zeile an meine ~/.zshrc an:
. "/home/alex/.acme.sh/acme.sh.env"
Der Inhalt dessen:
export LE_WORKING_DIR="/home/alex/.acme.sh"
alias acme.sh="/home/alex/.acme.sh/acme.sh"
Die beiden Zeilen hab ich aus der ~/.zshrc entfernt und stattdessen richtigerweise an ~/.zshenv angehängt. Ein entsprechendes Ticket upstream ist angelegt. Davon abgesehen, funktioniert das Skript aber sauber. Folgenden Aufruf hab ich benutzt:
acme.sh --issue -d owncloud.home.example.com -w /var/www/html/le --reloadcmd 'sudo -n /usr/sbin/service lighttpd reload' --post-hook '/home/alex/.acme.sh/create-lighty-pemfile.sh owncloud.home.example.com'
Wie man schon sieht, werden die challenge sachen später in einem webroot in oder unterhalb von /var/www/html/le landen. Die Dateirechte und Gruppenzugehörigkeit dieses Ordners sind so gesetzt, dass der unpriviligierte Nutzer mit seinem cronjob drin schreiben und der webserver draus lesen kann.
Die nötige Zeile für /etc/sudoers, damit der cronjob auch den Webserver neu starten kann:
alex ALL = NOPASSWD: /usr/sbin/service lighttpd reload
Daneben interessant ist sicherlich der post-hook, der nötig ist, weil lighttpd Zertifikat und private key zusammen in einer Datei erwartet, die Datei sieht so aus:
#!/bin/sh
ACMEDIR=/home/alex/.acme.sh
cat ${ACMEDIR}/${1}/${1}.cer ${ACMEDIR}/${1}/${1}.key > ${ACMEDIR}/${1}/${1}.lighty-pem
lighttpd
Der erste Teil der lighty-Konfiguration steht bei mir in /etc/lighttpd/lighttpd.conf und inkludiert meine ssl-Optionen:
$SERVER["socket"] == ":443" {
include "ssl/lighty-ssl.conf"
}
Diese Datei hab ich mir vom Mozilla SSL Configuration Generator erstellen lassen und von Hand angepasst. Die für den Betrieb mit acme.sh angepassten Zeilen:
ssl.pemfile = "/home/alex/.acme.sh/owncloud.home.example.com/owncloud.home.example.com.lighty-pem"
ssl.ca-file = "/home/alex/.acme.sh/owncloud.home.example.com/ca.cer"
Wobei die erste Datei diejenige ist, die unser post-hook Skript generiert und die zweite das CA Zertifikat, das acme.sh runterlädt.
Fehlen noch zwei Puzzlestücke. Bei Debian schmeißt man die typischerweise nach /etc/lighttpd/conf-available und kann sie später mit lighty-enable-mod und lighty-disable-mod leicht aktivieren und deaktivieren. Teil eins ist etwas kürzer und steckt hier in der Datei 53-le.conf und sieht so aus:
alias.url += ( "/.well-known/acme-challenge" => "/var/www/html/le/.well-known/acme-challenge/" )
Gut zu sehen, das zuvor in der acme Konfiguration angegebene webroot. Knifflig und etwas umfangreicher jetzt die owncloud-Konfiguration, hier mal aus der Datei /etc/lighttpd/conf-available/59-owncloud.conf in voller Länge:
$HTTP["host"] == "owncloud.home.example.com" {
# match all unencrypted traffic ...
$HTTP["scheme"] == "http" {
# but not the letsencrypt webroot ...
$HTTP["url"] !~ "^/\.well-known/acme-challenge" {
# and redirect as described on https://redmine.lighttpd.net/projects/lighttpd/wiki/HowToRedirectHttpToHttps
# capture vhost name with regex conditiona -> %0 in redirect pattern
# must be the most inner block to the redirect rule
$HTTP["host"] =~ ".*" {
url.redirect = (
".*" => "https://%0$0"
)
}
}
}
url.redirect = (
"^/.well-known/caldav$" => "/remote.php/caldav/",
"^/.well-known/carddav$" => "/remote.php/carddav/"
)
alias.url += ( "" => "/usr/share/owncloud" )
$HTTP["url"] =~ "^/data/" {
url.access-deny = ("")
}
$HTTP["url"] =~ "^($|/)" {
dir-listing.activate = "disable"
}
} else $HTTP["host"] =~ "" {
url.redirect = (
"^/owncloud/.well-known/caldav$" => "/owncloud/remote.php/caldav/",
"^/owncloud/.well-known/carddav$" => "/owncloud/remote.php/carddav/"
)
# Make ownCloud reachable under /owncloud
alias.url += ( "/owncloud" => "/usr/share/owncloud" )
# Taken from http://owncloud.org/support/distro-notes, section "lighttpd":
# As .htaccess files are ignored by lighttpd, you have to secure the /data
# folder by yourself, otherwise your owncloud.db database and user data is
# puplicly readable even if directory listing is off.
$HTTP["url"] =~ "^/owncloud/data/" {
url.access-deny = ("")
}
$HTTP["url"] =~ "^/owncloud($|/)" {
dir-listing.activate = "disable"
}
}
Was hier realisiert wird, ist die Umleitung von allem unverschlüsselten Traffic auf https außer für den Teil, der für die acme challenge unverschlüsselt bleiben muss. Dazu weitere well-known URLs für einfacheren Kalenderzugriff aus bestimmten Anwendungen, das Verbot das Datenverzeichnis zu erreichen und die Deaktivierung von directory listing, alles für owncloud, hat nichts mehr mit acme zu tun, auch der unterste Abschnitt dient nur nochmal zum Zugriff auf owncloud über andere Adressen.
Erzwingt man hier keinen Zugriff über https, kann man sich einiges der Konfiguration sparen, aber der Sinn von letsencrypt ist ja grad, möglichst viel über https abzuwickeln.
Übertragen der Zertifikate auf Reverse Proxy
In der Praxis hab ich den lighttpd nicht direkt am Netz hängen, davor ist noch ein nginx als Reverse Proxy, der HTTPS mit dem gleichen Zertifikat sprechen soll. Weil das hier thematisch nicht mehr so gut dazu passt, hab ich eine kleine Serie von Beiträgen draus gemacht. Zu Teil 2 hier entlang: Unbeaufsichtigte Aktionen mit SSH.