ownCloud: mit SSL-Proxy unter einer subdomain auf einem webpack von HostEurope

Es zeigt sich, dass eine durch Verschlüsselung gesicherte Verbindung zu einem öffentlichen Server nicht nur immer wichtiger wird, sondern auch immer verbreiteter ist. Für eine private Cloud-Anwendung sollte eine Verschlüsselung der Verbindung erst recht als zwingend angesehen werden.

Eine gesicherte Verbindung setzt den Einsatz von SSL-Zertifikaten voraus. Bei vielen Providern wird an dieser Stelle eine Beschränkung der gebuchten Pakete deutlich. Der Webspace ist ausgelegt für ein CMS oder vergleichbare Anwendungen, die unverschlüsselt über Port 80 aufgerufen werden. SSL-Zertifikate können nicht installiert werden.

Hier zeige ich euch, wie man den Webspace auf einem webpack bei HostEurope, einem ausgezeichtenen Provider, mit seinem SSL-Proxy absichert und einen verschlüsselten Zugriff über Port 443 einrichten kann.

Die Anwendung soll dabei über eine Third-Level Domain bzw. eine Sub-Domain erreichbar sein.

1. Konfiguration von ownCloud anpassen

Die Konfigurationsdatei ist zu finden unter:
owncloud/config/config.php

Parameter ‘trusted_domains’ ändern:

 

Weiter unten ergänzen:

Die Anwendung ist nun noch über beide Ports (80 und 443) erreichbar, springt nach der Anmeldung aber auch hin und her. Das Backend wird nicht geladen.

Es fehlt noch:

2. die Anpassung der .htaccess

Im Verzeichnis von ownCloud findet man eine Datei .htaccess
owncloud/.htaccess

Datei öffnen und editieren. Unter dem Eintrag RewriteEngine On ergänzt man (hier am Beispiel vom HostEurope-SSL-Proxy mit vier IP-Adressen):

3. Ergebnis

Wird ownCloud unter der Sub-Domain aufgerufen:
http://sub.domain.tld”,
erfolgt nun automatisch eine Umleitung auf die verschlüsselte Instanz von ownCloud hinter dem SSL-Proxy über Port 443:
https://ssl.webpack.de/sub.domain.tld“.

Dieser URL ist sicherlich nicht soooo schön, eher schwerfällig, aber dafür ist die Verbindung zur eigenen Cloud nun sicher! Das gilt für alle clients wie zum Beispiel ein Handy bzw. ein mobile phone, oder Thunderbird. Für den Austausch von Daten oder die Synchronisation von Terminen gibt es eine Reihe von Apps für Windows Phone, iPhone iOS oder Android und natürlich für Desktops unter MacOS, Windows oder Linux.

Sicheres WebDAV ist beispielsweise möglich über die Adresse:
https://ssl.webpack.de/SUB.DOMAIN.TLD/remote.php/webdav/

Die Verwaltung von Kalendern erfolgt über:
https://ssl.webpack.de/sub.domain.de/remote.php/caldav/calendars/USER/calendar-name

Sicheres CalDAV ist möglich über:
https://ssl.webpack.de/sub.domain.de/remote.php/caldav/
für iOS über:
https://ssl.webpack.de/sub.domain.de/remote.php/caldav/principals/USERNAME/

Lightning ist ein Plugin für Thunderbird und ermöglicht die Verwaltung von Kalendern und Aufgaben.

Sicheres CardDAV ist möglich über:
https://ssl.webpack.de/sub.domain.de/remote.php/carddav/addressbooks/USERNAME/contacs

Damit können Adressbücher synchronisiert werden. Für Thunderbird gibt es das Plugin: SOGo Connector Thunderbird extension.


4. Ab Oktober 2016

Im Oktober 2016 hat HostEurope offenbar einige Änderungen am SSL-Proxy vorgenommen.
#Tobias gab in den Kommentaren den entscheidenden Hinweis, den ich hier noch einmal wiederhole:

Anpassung der .htaccess

Im Verzeichnis von ownCloud findet man eine Datei .htaccess
owncloud/.htaccess

Datei öffnen und editieren. Unter dem Eintrag RewriteEngine On ändert man:

in:

Änderung in der Konfiguration von ownCloud

Die Konfigurationsdatei ist zu finden beispielsweise unter:
owncloud/config/config.php

Darin die folgende Zeile löschen oder, wie in diesem Beispiel geschehen, auskommentieren

Hier noch einmal das Ergebnis

Wird ownCloud unter der Sub-Domain aufgerufen “http://sub.domain.tld”,
erfolgt nun automatisch eine Umleitung auf die verschlüsselte Instanz von ownCloud hinter dem SSL-Proxy über Port 443:
https://ssl.webpack.de/sub.domain.tld“.

Share

20 thoughts on “ownCloud: mit SSL-Proxy unter einer subdomain auf einem webpack von HostEurope

  1. Hallo,

    soweit klappt alles. Problem ist nur (egal bei welcher Anleitung), dass die Login-Maske nicht funktioniert. Sämtliche Bilder Styles etc. laden nicht und der Login-Button klappt nicht.
    Irgendeine Idee für sowas? Ich steh völlig aufm Schlauch.

    Gruß

    Dirk

    1. Hallo Dirk,

      über Deine Anfrage freue ich mich sehr!
      Vorab der Hinweis: die obige Anleitung funktioniert auch mit der aktuellen owncloud Version 8.2.1 weiterhin tadellos.

      Hast Du den Web Installer benutzt?
      Was Du oben beschreibst, habe ich auch beobachtet. Soweit ich mich erinnere trat dieses Phänomen dann auf, wenn owncloud mit dem Web Installer installiert wurde.
      Versuche es alternativ mit dem gepackten .tar.bz2 oder .zip Archiv! Damit klappt es bei mir auf allen Servern problemlos.

      Grundsätzlich muss in diesem Zusammenhang aber immer auch auf die korrekten Besitz- und Zugriffsrechte für Ordner und Dateien hingewiesen werden! Diese kannst Du im KIS –> Dateiverwaltung kontrollieren oder ändern. Auch die FTP-Zugänge müssen dementsprechend konfiguriert werden!

  2. Hallo,
    auch ich habe das Problem mit der Log-in Maske unter SSL (http funktioniert). Ich habe sowohl den Web-Installer als auch das .tar.bz2 Archiv versucht. Beide Male mit dem gleichen Ergebnis. (Version ist 8.2.1.4).
    – Ist es egal, an welcher Stelle in der config.php die Einträge ‘overwritehost’… ergänzt werden? (Solange es vor dem abschließenden “);” ist)
    – Muss der Parameter “‘overwrite.cli.url” verändert werden? Der verweist bei mir auf den ursprünglichen Pfad ohne SSL-Proxy?
    Ich wäre für einen Tip sehr dankbar.
    Viele Grüße, Markus

  3. Erfolg! Ich habe es selbst ausprobiert: Wenn ich die Einträge am Ende der config.php ergänze, funktioniert ssl. (ohne zwar nicht mehr, aber das ist mir egal!) Gruß, Markus

  4. Tausend Dank für die Anleitung, sehr einfach. Sollte auch auf Anhieb klappen, wenn man nicht wie ich versucht als HE-Proxy-IP die IP-Adresse des eigenen Servers einzutragen … mit der Login-Maske hatte ich keine Probleme.

  5. Ja, funktionert auch mit OC9. Leider gibt es nur jetzt immer einen Fehler bei der “Integritätsprüfung”, da die .htaccess-Datei modifiziert werden muss. Hat jemand hierfür einen workaround, um diesen Fehler abzustellen?

    Klar, ich meine das ist mehr ein kosmetisches Problem, da man die eigene Modifizierung ja nachvollziehen kann und dementsprechend in der Liste der geänderten Dateien sieht, dass es eben “nur” die .htaccess-Datei ist. Aber einerseits senkt das die Aufmerksamkeit auf einen möglichen echten Angriff, weil die “Fehlermeldung” dann eben standardmäßig bei jedem Aufruf des Webinterface aufleuchtet. Zum anderen könnte die .htaccess-Datei ja auch von einem Angreifer manipuliert werden, was so ebenfalls unbemerkt bleiben könnte.

    1. Das ist relativ einfach, da die Integritätsprüfung normalerweise nur einmal nach dem Update ausgeführt wird (vgl. z.B. https://github.com/owncloud/core/issues/22966). Ich gehe immer folgendermaßen vor:

      Unmittelbar nach jedem Update rufe ich die oc erst mal ohne Anpassung der .htaccess über https://ssl.webpack.de/sub.domain.tld auf. Dann passiert das Update der Datenbank und der Integritätscheck. Sobald dann das Update komplett gelaufen ist, passe ich dann noch die .htaccess an.

      Sollte das Update schon gelaufen und der Integritätscheck bereits fehlgeschlagen sein: .htaccess nochmal durch das Original ersetzen und über die Admin-Seite den Integritätscheck erneut anstoßen. Anschließend kann die .htaccess wieder wie angepasst werden.

  6. Die Installation mit dem Web-Installer hat einwandfrei funktioniert. Allerdings will ich dem Bespiel hier folgen um OC9 via SSL aufzurufen … bekomme ich die Meldung:

    Fehler: Umleitungsfehler
    Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
    Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden.

    Wo könnte da mein Fehler liegen?

    1. Hallo Jan, meine Owncloud-Installation (via SSL-Proxy) auf Hosteurope bringt seit neuestem ebenfalls den Umleitungsfehler. Bis vor kurzem hat alles wunderbar funktioniert. Hast du eine Lösung für dein Problem gefunden. Ich weiß gar nicht, wo ich mit der Suche beginnen soll. Danke.

    2. Zur Behebung des Umleitungsfehlers in der htaccess folgende Zeilen löschen:

      RewriteCond %{REMOTE_ADDR} !^10\.30\.7\.1(?:37|38|39|40)$
      RewriteRule ^ https://ssl.webpack.de/%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

      … und durch folgende Zeilen ersetzen:

      RewriteCond %{HTTP:Via} !ssl.webpack.de
      RewriteRule ^ https://ssl.webpack.de/%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

      Zusätzlich in der config.php die entsprechende Zeile löschen:

      ‘overwritecondaddr’ => ‘^10\\.30\\.7\\.1(?:37|38|39|40)$’,

      Hat bei mir funktioniert.

      1. Der Hinweis von Tobias war genau richtig!
        Ich habe das inzwischen erfolgreich ausprobiert. Funktioniert perfekt – auch auf älteren Server-Umgebungen sowie mit Versionen 8 oder 9 von owncloud.
        Offensichtlich hat HE am SSL-Proxy Änderungen vorgenommen.

  7. Danke für diese Anleitung. Hat mir sehr geholfen.

    Noch ein Hinweis zur Kalender-URL und dem Einsatz unter Lightning/ Thunderbird:
    Bei Owncloud 9.1.x funktioniert https://ssl.webpack.de/sub.domain.de/remote.php/caldav/ zwar unter Android (mit entsprechender App CalDAV-Sync) bei mir, aber nicht unter Lightning.
    Die URL, die Owncloud (in Calendar-App unter “… (mehr)” sowie “Verweis” anbietet lautet: https://ssl.webpack.de/sub.domain.de/remote.php/dav/calendars//personal/

  8. Als Strorage Engine ist auf allen Servern nun auch InnoDB möglich. Damit können alle Instanzen von Owncloud auf die neueste Version gehoben werden.

    Übrigens funktioniert auch Nextcloud perfekt!

    Diese Anleitung wurde getestet und funktioniert auch mit Nextcloud 11.0.3

  9. Benutzt jemand als WebDAV Cyberduck und kann über den SSL-Proxy auf seine ownCloud-Installation zugreifen? Wenn ja, wie haben Sie den Server angegeben?

    Danke.

    1. Hier in diesem Kontext mit einer Subdomain lautet die Adresse:
      https://ssl.webpack.de/sub.domain.tld/remote.php/webdav/

      In Cyberduck wählst Du
      –> Verbindung –> WebDAV (HTTP/SSL), als
      –> Server trägst Du ein: ssl.webpack.de/sub.domain.tld/remote.php/webdav/
      –> Port 443

      Du könntest auf dem Mac oder unter Linux auch den Menübefehl “Mit Server verbinden” klicken und als Adresse angeben:
      davs://USERNAME@ssl.webpack.de/sub.domain.tld/remote.php/webdav/

Leave a Reply

Your email address will not be published. Required fields are marked *