Bester CalDAV-Server überhaupt (wenn man der einzige Benutzer ist)

Bis vor kurzem habe ich zur Synchronisation meiner Kontakte und meines Kalenders Owncloud benutzt, um zu vermeiden, dass alle meine Daten bei Google liegen. Owncloud habe ich damals gewählt, weil es mir aufgrund der hohen Verbreitung als die einfachste Lösung erschien. Was von so vielen Leuten benutzt wird, kann so schlecht ja gar nicht sein.

Falsch gedacht! Owncloud ist einfach nur schrecklich! Es gibt keine Autoupdatefunktion, man muss aber ständig updaten, weil immer wieder hochkritische Sicherheitslücken auftauchen. Man wird nicht einmal informiert, wenn ein neues Update verfügbar ist. Und wenn man mal wieder updaten muss, weil man erfahren hat, dass seine ganze Serverinfrastruktur bedroht ist*, muss man eine extrem lange Liste von Schritten manuell abarbeiten, nur um festzustellen, dass irgendwas doch kaputt gegangen ist und man bis nachts um drei da sitzen muss um es zu fixen, weil man auf die Synchronisierung seiner Kalenderdaten angewiesen ist.

Performant ist es auch nicht, da CalDAV und CardDAV eigentlich nicht die Hauptfunktionalität von Owncloud sind und man noch einen riesigen Overhead an „Cloud“-Funktionalitäten hat. Außerdem musste ich manchmal an der Korrektheit der Software zweifeln – auch wenn ich nicht beweisen kann, dass es an Owncloud lag – da irgendwann mal ein paar Aufgaben im Kalender gefehlt haben, und dafür ein paar andere doppelt waren.

Baikal for the Rescue

Nun habe ich mit Baikal einen neuen CalDAV-Server gefunden und ich muss wirklich sagen, er erfüllt (fast) alle meine Ansprüche.

Zuallererst bringt Baikal keinen unnötigen Schnickschnack mit, sondern nur die CalDAV/CardDAV-Funktionalität. Ein kleines Admin-Webinterface ist auch dabei, sonst nichts. Es ist relativ leicht zu installieren, scheint recht effizient zu laufen und funktioniert einwandfrei. Eine gute Installationsanleitung findet sich hier. Ich habe zuerst Version 0.2.7 installiert und vor ein paar Tagen auf 0.3.4 geupdatet und hatte überhaupt keine Probleme damit.

Ist Baikal also Perfekt?

Wie jede andere Software hat Baikal auch seine Nachteile. Zum einen ist die Dokumentation miserabel und die Funktionalität findet sich nicht immer da, wo man sie gerade erwartet hätte. So ist das Webinterface beispielsweise nur vom Benutzer „admin“ benutzbar, was bei mir zuerst für Verwirrung gesorgt hat (Der Benutzername ist sogar hardgecodet, ich hab es mir im Code angesehen). Normale Benutzer können so keine eigenen Kalender über das Admininterface anlegen. Das geht nur direkt über das darunterliegende SabreDAV in einem extrem hässlichen Interface. Wie man als normaler Nutzer sein Passwort ändert, habe ich noch nicht herausgefunden. Da ich aber der einzige Benutzer bin, stört mich das alles nicht.

Die Entwickler scheinen außerdem nicht wirklich auf Sicherheit bedacht zu sein. Das Webinterface ist durchgehend anfällig für CSRF und man kann mit einem einfachen GET-Request ganze Benutzer und ihre Kalender aus der Datenbank löschen, was die Entwickler aber nicht zu stören scheint. Auf der GitHub-Seite gibt es schon seit einiger Zeit ein Issue dafür, die Entwickler meinen aber, es gebe „wichtigeres“ zu tun.

Zugegebenermaßen hat auch Baikal keine Autoupdatefunktion, das Updaten geht jedoch viel schneller und einfacher als bei Owncloud und lässt sich wahrscheinlich mit einem Skript automatisieren.

Wenn man aber der einzige Benutzer dieser Software ist, der sich darüber hinaus nur einmal ins Admininterface eingeloggt hat, um seine Kalender zu erstellen und sie dann einfach nur laufen lässt, ist Baikal wohl der beste CalDAV-Server, den es gibt.

Fußnoten:

* OK, so schlimm ist es nun auch nicht. Die kritischen Code-Execution-Lücken konnten nur von authentifizierten Nutzern durchgeführt werden und ich bin der einzige Benutzer. Für Installationen mit nicht vertrauenswürdigen Nutzern (alle Nutzer außer dem Admin) trifft das aber dennoch zu.

Let’s Encrypt ist das Beste überhaupt

SSL-Zertifikate zu erstellen war früher sehr nervig. Zuerst musste man sich mit dem unzumutbaren OpenSSL-Syntax herum ärgern und dann die überteuerten Preise der „Zertifikatsmafia“ bezahlen, um ein von Browsern akzeptiertes Zertifikat zu erhalten. (Technisch gesehen war es möglich von StartSSL kostenlose Zertifikate zu bekommen, allerdings nicht für Subdomains und das Widerrufen von Zertifikaten war sehr teuer.)

Zum Glück ändert sich das jetzt, da Let’s Encrypt seit einiger Zeit in der Public-Beta Phase ist. Let’s Encrypt ist eine Certificate Authority (CA), die unter anderem von Mozilla und der EFF gesponsert wird und deren Ziel es ist, das Erstellen von SSL-Zertifikaten unkompliziert zu machen. Dadurch soll verschlüsselter Datentransfer im Internet gefördert werden. Durch den einmaligen Aufruf eines Kommandozeilenprogramms wird ein von Let’s Encrypt validiertes Zertifikat erstellt und der Webserver dazu konfiguriert, es zu benutzen. Und das beste ist, es kostet überhaupt nichts.

Da Let’s Encrypt noch in der Public-Beta ist, ist das ganze noch nicht so komfortabel, wie es einmal sein soll. Es ist jedoch hundertmal einfacher als mit der klassischen Methode.

Da ich Ubuntu-Server 14.04 benutze, und es dafür noch kein Paket gibt, musste ich erst mal das Git-Repository klonen. Dort steht der Wrapper „letsencrypt-auto“ bereit, der Abhängigkeiten für den Client automatisch auflöst und automatische Updates durchführt.

Für die Validierung der Domain und das Erstellen und die Installation des Zertifikats stehen verschiedene Optionen zur Verfügung. Eine davon ist, dass der Let’s Encrypt Client direkt über den Webserver die Validierung durchführt und das erhaltene Zertifikat automatisch auf diesem installiert. Da ich aber keine Lust darauf habe, dass experimentelle Software mir in meiner Serverkonfiguration herum pfuscht, habe ich die „webroot“-Variante gewählt. Dabei wird im obersten Verzeichnis der Webseite („webroot“) der zu validierenden Domain ein Token platziert, das vorher vom Validerungsserver erhalten wurde und das dieser dann abruft und so den Besitz der Domain bestätigt. Das Zertifikat wird bei dieser Variante nicht automatisch installiert. Wenn man für seinen Server bereits SSL-Zertifikate eingerichtet hat, ist das aber kein nennenswerter Mehraufwand.

Ein Zertifikat für alle meine SSL-verschlüsselten Webseiten konnte ich so mit

$ ./letsencrypt-auto certonly --webroot --webroot-path /var/www/wordpress -d 'jonas-moennig.de' -d 'www.jonas-moennig.de' \
--webroot-path /var/www/piwik -d 'piwik.jonas-moennig.de' -d 'www.piwik.jonas-moennig.de' \
--webroot-path /var/www/baikal/html -d 'baikal.jonas-moennig.de' --email jonas@jonas-moennig.de

erhalten.

Die Zertifikate sind nur für 90 Tage gültig, aber das macht nichts, da das Erneuern der Zertifikate noch viel einfacher ist als das Erstellen:

$ ./letsencrypt-auto renew --email jonas@jonas-moennig.de --agree-tos

erneuert alle Zertifikate, die in den nächsten 30 Tagen ablaufen automatisch. Die aktuellen Zertifikate werden immer in /etc/letsencrypt/live/<domain>/fullchain.pem und der dazugehörige Schlüssel in /etc/letsencrypt/live/<domain>/privkey.pem gespeichert, sodass man seine Webserverkonfiguration überhaupt nicht anfassen muss.

Man kann durchaus sagen, dass Let’s Encrypt das Erstellen von SSL-Zertifikaten revolutioniert hat und in den nächsten Jahren maßgeblich dazu beitragen wird, dass Verschlüsselung im Internet noch häufiger Anwendung findet.