Die eigene Cloud auf dem Raspberry PI (Teil 1: lighttpd und SSL)

Bereits vor einiger Zeit habe ich mir einen Raspberry Pi gekauft, einen Ein-Platinen-Computer in der Größe einer Scheckkarte. Es stand nicht wirklich eine Notwendigkeit dahinter, eher technische Neugier gepaart mit einer relativ niedrigen Kaufschwelle von rund 25 USD.

Jetzt habe ich auch endlich eine Verwendung für die Himbeere 3,1415 gefunden: Meine eigene, kleine Cloud – mein Wölkchen also.

Motivation

Zunächst möchte ich noch meine Zielsetzung schärfen: Trotz der Auswahl von ownCloud als Server-Software geht es mir primär nicht um die Einrichtung einer Dateiablage oder ähnlichem. Vielmehr steht der weltweite Zugriff auf Kontakte und Kalenderdaten via Browser oder mobilem Endgerät im Vordergrund. Die dafür notwendigen Protokolle CalDAV und CardDAV sind in ownCloud integriert und die Installation der ownCloud-Software ist um ein Vielfaches einfacher als der dedizierten Varianten (z.B. DaviCAL).

Zwar kann man alle Leistungen kostenlos bei Google bekommen, doch liegen die persönlichen Daten dann eben bei Google. Natürlich muß das nicht zwangsläufig zu Mißbrauch führen (Don’t be evil, sagt Google). Aber ab und an wird Google sicherlich mal einen Blick auf die Daten werden, um die Benutzererfahrung zu verbessern. Anders wären Dienste wie Google Now gar nicht möglich.

Hard- und Software-Basis

Meine Beschreibung orientiert sich dabei an den Möglichkeiten eines Raspberry Pi, Modell B, 256MB Variante. Als Betriebssystem kommt die Debian Wheezy basierte Raspbian-Distribution zum Einsatz. Wegen der begrenzten Ressourcen wird nicht auf das ownCloud-Paket der Distribution zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Stattdessen wird auf LigHTTPd zurückgegriffen:
$ sudo apt-get install lighttpd

Damit ist der Webserver bereits installiert und liefert sein Platzhalter-Seite über HTTP aus. Allerdings handelt es sich um eine unverschlüsselte Verbindung. Die später notwendigen Anmelde-, meine Kontakt- und Kalenderdaten sollen so nicht verschickt werden. Vielmehr muß eine Absicherung über TLS, besser bekannt als SSL.

Absicherung der Kommunikation

Ich will erreichen, daß die Kommunikation mit den Clients (iPhone, Browser, etc.) verschlüsselt abläuft. Dazu würde theoretisch ein einfaches, selbst-signiertes Zertifikat reichen. Allerdings würden dann unbedarfte Anwender mit Dialogen konfrontiert werden, in denen Begriffe wie Gefahr, Sicherheitshinweis und nicht empfohlen vorkommen.

Der Grund ist, daß ein selbst-signiertes Zertifikat zwar für den Aufbau einer verschlüsselten Verbindung ausreicht, aber die Identität des Servers nicht bestätigt. Dies geht nur über eine Zertifikatskette, welche ausschließlich aus dem Client bekannten Certification Authorities (CA) besteht. Das heißt: Eine dem Client bekannte und als vertrauenswürdig eingestufte CA hat die Validität meines Server-Zertifikats mit ihrer Signatur bestätigt.

In meiner Beschreibung verwende ich als Hostnamen owncloud.dahlen.org und einen Benutzer namens cloudmaster. Weder die Domäne, noch der Benutzer existieren in der Realität.

Leider verlangen die im Browser vorinstallierten CAs teilweise horrende Gebühren für ihre Signatur. Doch es gibt kostenlose Ausnahmen, welche für meinen Anwendungsfall auch völlig ausreichend sind. Eine davon ist die Firma StartSSL.

Wichtig: Für die Erstellung eines durch StartSSL-signierten Zertifikats wird die eigene Domäne benötigt (wie dahlen.org). Ohne diese Domäne bleibt euch nur die Möglichkeit eines selbst-signierten Zertifikats. Auch muß der ownCloud-Host über einen Fully Qualified Domain Name (FQDN) erreichbar sein, also über einen Namen wie owncloud.dahlen.org.

Das erforderliche Software (OpenSSL) sollte bereits bei der Installation von Raspian mitgekommen sein, ansonsten schadet eine erneuter Versuch auch nicht.
$ sudo apt-get install openssl

Schlüssel und Zertifikate

Zunächst erstellt man einen privaten Schlüssel, mit welchem das spätere Server-Zertifikat abgesichert ist. Auf die Möglichkeit, diesen private key mit einem weiteren Kennwort abzusichern wird bewußt verzichtet:
$ openssl genrsa -out server.key 2048

Dann erstellt man einen Certificate Signing Request (CSR), eigentlich ist das der öffentliche Teil des privaten Schlüssels, welcher zur Signatur bei der CA eingereicht wird (oder eben selbst signiert wird):
$ openssl req -new -key server.key -out server.csr

Die gestellten Fragen sind gemäß der eigenen Umgebung anzugeben. Wichtig dabei: Das Feld Common Name (CN) muß den Namen und die Domäne (Fully Qualified Domain Name, FQDN) des eigenen ownCloud-Servers beinhalten. Der vollständige Dialog kann also wie folgt aussehen:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:Toenisvorst
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:owncloud.dahlen.org
Email Address []:cloudmaster@dahlen.org

Der erzeugte CSR wird jetzt bei StartSSL zur Signatur eingereicht. Diesen Prozeß muß ich glücklicherweise nicht beschreiben, denn das haben die Kollegen auf heise Security bereits getan. Im Ergebnis wird das signierte Zertifikat angezeigt, welches man kopiert und eine Datei namens server.crt speichert. Es ist dabei enorm wichtig, daß der Inhalt der Datei nicht durch Umbrüche oder ähnliches verändert wird.

Drei Dateien befinden sich nun im aktuellen Verzeichnis:

  • server.key – der private Schüssel zum Zertifikat
  • server.csr – der öffentliche, unsignierte Schlüssel
  • server.crt – das öffentliche, signierte und damit „zertifizierte“ Schlüssel

Der CSR wird nicht mehr benötigt und kann gelöscht werden. Eine weitere Datei muss noch besorgt werden, um die Kette der Zertifikat-Signaturen zu schliessen: Das Intermediate Certificate von StartSSL. Diese lässt sich direkt abrufen:
$ wget -O ca.pem http://www.startssl.com/certs/sub.class1.server.ca.pem

Damit ist die Zertifikatskette geschlossen und die Gültigkeit des eigenen Server-Zertifikats kann überprüft werden:
$ openssl verify -CAfile ca.pem server.crt
Erwartetes Ergebnis:

server.crt: OK

Als letzten Schritt der Zertifikat-Vorbereitung müssen jetzt noch der private Schlüssel und das Zertifikat in eine Datei überführt werden.
$ cat server.key server.crt > server.pem

Installation in lighttpd

Nun ist es Zeit, die generierten Teile der SSL-Infrastruktur dem Webserver bekannt zu machen:
$ sudo cp server.pem /etc/lighttpd/
$ sudo cp ca.pem /etc/lighttpd/

Außerdem muß die Konfiguration unter /etc/lighttpd/lighttpd.conf angepasst werden. Die Änderungen beginnen mit der Änderung der Port-Nummer (ca. ab Zeile 15). Aus
server.port = 80
wird
server.port = 443
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.ca-file = "/etc/lighttpd/ca.pem"

Letztendlich wird damit der Zugriff über einfaches, unverschlüsseltes HTTP abgeschaltet. Durch einen Neustart wird dies aktiviert:
$ sudo service lighttpd restart

Danach ist der Dienst nur noch über HTTPS auf Port 443 zu erreichen, also https://owncloud.dahlen.org/.

Im nächsten Teil beschreibe ich, wie jetzt ownCloud ins Spiel kommt.

  1. Jürgen sagt:

    Hallo,
    habe zu Weihnachten auch einen Raspberry bekommen und will mit ihm nun meine eigene Wolke installieren. So einiges funktioniert auch schon 🙂 – auch Dank dieser Anleitung!

    Frage zur SSL-Konfiguration.
    Der Raspberry hängt an meinem DSL-Anschluss und bekommt alle 24h eine neue IP-Adresse. Über Dynamic DNS ist er über einen festen Namen erreichbar
    (Also z.B. beispiel.dd-dns.de)

    Wenn ich das richtig verstehe, steht das im Widerspruch zur SSL-Konfiguration (zumindest will startssl.com ja eine „richtige“ dommain).

    Gibt es da eine Lösung?

    Viele Grüße
    Jürgen

  2. Christoph sagt:

    Hallo Jürgen,

    ich würde erwarten, daß auch eine DynDNS Domäne mit einem SSL-Zertifikat belegt werden kann, es ist ja eine „richtige“ Domäne. Meines Wissens wird der Name im Zertifikat (Common Name, CN) mit dem Host-Header des eingehenden Requests verglichen und der bleibt ja (auch bei wechselnder IP) stabil.

    Gruß

    Christoph

  3. Markus sagt:

    Hi
    habe das ganze ohne StartSLL gemacht und habe folgende Frage.
    Hab dies selbst signiert.
    openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

    Nun fehlt mir aber weiter unten die ca.pem
    die hast du dir ja von StartSLL geholt.
    Was muss ich hier machen um die entsprechende Datei zu bekommen?
    Oder brauche ich die in meinem Fall nicht?

  4. Christoph sagt:

    Ich glaube, den Teil kannst Du Dir sparen, bei selbst-signierten Zertifikaten wird es so oder so eine Warnung geben.

    Gruß

    Christoph

  5. Markus sagt:

    Die Warnung ist mir nicht so schlimm.
    Soll das heißen ich brauche nur den Befehl ausführen
    $ sudo cp server.pem /etc/lighttpd/
    und den hier kann ich weg lassen
    $ sudo cp ca.pem /etc/lighttpd/

    und in /etc/lighttpd/lighttpd.conf

    lasse ich das hier einfach weg?
    ssl.ca-file = „/etc/lighttpd/ca.pem“

  6. Christoph sagt:

    Hi Markus,

    wenn Du kein CA-Zertifikat hast (ca.pem), dann kannst Du es auch in der lighttpd.conf nicht referenzieren. Es ist also beides richtig, Du brauchst die Datei nicht kopieren und Du mußt den Eintrag in der Konfiguration weglassen.

    Gruß

    Christoph

  7. Heiner sagt:

    Hi,

    bei mir klappt der Schritt
    openssl req -new -key server.key -out server.csr

    nicht. Ich beantworte die Fragen aber nach der letzten kommt einfach wieder mein Prompt. folglich kann ich die Server.crt nicht erzeugen um eine Ausgabe da reinzukopieren. auch in der Hofnfung das passiert automatisch geht nicht auf, die Datei gibt’s nicht.

    Was mache ich falsch?

    Danke fuer die Hilfe

  8. Christoph sagt:

    Hallo Heiner,

    vielleicht hilft mein Blick in meine andere Artikelserie, insbesondere den 2. Teil, indem ich mich – losgelöst vom Thema ownCloud – mit Zertifikaten und deren Erzeugung beschäftige.

    Gruß

    Christoph

Kommentar hinterlassen