Entries tagged as https

HTTPS für Seafile mit Nginx

Lang, lang ist's her, dass ich meinen letzten Eintrag hier tätigte, aber zum Jahresende gab's so einiges zu tun und ich hatte keine Zeit und Muße zu schreiben. Jetzt aber ist alles wieder ein wenig ruhiger und ich nutze gerade die Zeit, da ich mir 'ne dicke Erkältung eingefangen habe, meinen Seafile-Server auf HTTPS umzustellen. Anleitungen gibt's dazu so einige wie z.B. unter:

http://jankarres.de/2013/06/raspberry-pi-owncloud-alternative-seafile-server-installieren/
oder direkt bei Seafile: http://manual.seafile.com/deploy/deploy_with_nginx.html

Die Anleitung von Jan Karres zur Installation und Einrichtung von Nginx und die Anpassung von Seafile ist gut erklärt und führt i.d.R. zum Ziel. Bei mir jedoch hakte die Umstellung ein wenig, da ich den Standardport für Seafile bei mir durch einen anderen ersetzt hatte und so machte ich bei der Umstellung einen Denkfehler und wunderte mich, weshalb das Rewrite von http:// auf https:// nicht klappte und weshalb die Seite partout nicht erreichbar war (502 Bad Gateway seitens Nginx).

Ok, eine zusätzliche Portfreigabe für den neuen Port für https:// hatte ich im Router bereits eingerichtet, doch ich kam bei der Konfiguration von Nginx und dem Starten von Seahub via "fastcgi" durcheinander.
Aber nach einer kleinen Denkpause kam ich auf den Trichter und löste das ganze schließlich so:

Seafile:

QUOTE:
SERVICE_URL in der ccnet.conf lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)
FILE_SERVER_ROOT in der seahub_settings.py lautet nun: https://meinserver:4001 (Port von 4000 http auf 4001 für https geändert)


In meiner für Seafile angelegten Site für nginx ("seahub") lauten die Einträge nun:

QUOTE:
server {
listen 4000;
server_name meinserver;
rewrite ^/(.*)$ https://$host:4001/$1; # Port mit angegeben, da die Weiterleitung sonst nicht klappt
}

server {
listen 4001;
ssl on;
[...]
fastcgi_pass 127.0.0.1:8000;
[...]
}


Danach startete ich Seahub per ./seahub.sh start-fastcgi und startete den Nginx-Dienst per "sudo service nginx start" neu.
Jetzt ist die Seite via https://meinserver:4001 zu erreichen sowie bisher über http://meinserver:4000, wobei bei letzterer Adresse eine Weiterleitung erfolgt.

Im Client änderte ich die Adresse noch ab und deaktivierte die Zertifikatsprüfung und komme jetzt wieder ins Webinterface und der Client verbindet sich sauber.


Weshalb das Starten von Seahub oder Nginx davor immer fehlschlug, lag daran, dass ich Seahub per "./seahub.sh start-fastcgi 4001" starten wollte und Nginx beim Starten dann meckerte: ""bind() to 0.0.0.0:4001 failed (98: Address already in use)".
Startete ich zuerst den Nginx Dienst und dann Seahub per "./seahub.sh start-fastcgi 4001", wollte Seahub nicht mehr starten.
Die Lösung ist dabei so einfach, wie für mich anfänglich aber nicht klar: In der Nginx Site muss (!) der fastcgi Wert "fastcgi_pass" auf 127.0.0.1:8000 stehen und Seahub muss per: "./seahub.sh start-fastcgi" ohne weitere Portangabe gestartet werden. Danach läuft Nginx sauber, hört auf die angegebenen Ports und leitet Anfragen entsprechend weiter.
Ich hatte mich schlichtweg zu sehr am Port 8000 gestört, den ich partout nicht haben wollte, weil ich ja bewusst einen anderen ausgewählt hatte.

Kaspersky 2015/2016 blockiert HTTPS-Verbindung u.a. für Youtube, Google usw.

Ich peppte mein betagtes ACER Notebook auf, indem ich ihm eine SSD und Windows 10 spendierte. Seitdem rennt es wieder ordentlich. Zusätzlich installierte ich die Kaspersky Internet Security Suite in der aktuellsten Version.
Als ich dann jedoch mit Firefox Youtube, Google und andere Seiten aufrufen wollte, erhielt ich nur die Meldung, dass der Seite nicht vertraut werden könne. Eine Möglichkeit, die Seite(n) zu den Ausnahmen hinzuzufügen hatte ich allerdings nicht. In Vivaldi sowie im Edge klappte der Seitenaufruf jedoch problemlos. Zudem schienen nur HTTPS-Seiten betroffen zu sein.

Da war mal was, fiel mir ein. In einer älteren Version (2014 ?!) musste man aus dem Windows Zertifikatsspeicher (certmgr.msc) das Kaspersky Root Zertifikat aus "Zwischenzertifizierungsstellen/Zertifikaten" löschen und anschließend die "cert8.db" aus dem Firefox Profilordner. Doch in meinem Fall gab's das Kaspersky Zertifikat nicht, sondern nur ein Kaspersky Anti-Virus Personal Root Certificate unter "Vertrauenswürdige Stammzertifikate/Zertifikate", welches ich erst einmal nicht löschen wollte.

Gab's da nicht auch mal eine andere Lösung ? Und ja: in den Kasperskyeinstellungen unter: "Einstellungen/Erweitertet/Netzwerk/Untersuchung von sicheren Verbindungen" muss der Punkt: "Sichere Verbindungen nicht untersuchen", ausgewählt werden. Und dann klappt's auch mit dem Firefox und HTTPS-Seiten wieder.

Das kann sicherlich nicht im Sinne des Erfinders sein, ist derzeit aber der einzig wirklich funktionierende Weg. ^^

Page 1 of 1, totaling 2 entries