Loginmasken auf verschiedenen Ports via SSL absichern

J

JustARandomDude

New Member
Guten Abend,
ich hab mich mal hier angemeldet in der Hoffnung das mir hier jemand weiterhelfen kann. Ich habe folgendes Setup:
Debian 9 Server mit Aktuellem Plesk Obsidian, Docker mit diversen Applikationen in Containern und Erreichbaren Logins nach außen.

Mein Problem: Ich würde natürlich gerne die Logins über Https laufen lassen, Plesk stellt mich hier aber vor Probleme.

Was ich bisher versucht habe: Ich habe Setup auf einem 2. Test Server laufen ohne Plesk, dort klappt alles Wunder-prächtig. Ich habe also eine funktionierende ngin.conf mit direktiven die eigentlich funktionieren sollten. Ich habe die entsprechenden direktiven aus dem entsprechenden "Server" key der nginx.conf genommen und in Plesk in die Domain "Apache & nginx Settings" eingetragen bei den Zusätzlichen nginx direktiven. Pleks nimmt diese auch an, jedoch habe ich auf dem Konfigurierten Port einen SSL Fehler und Firefox meldet "rx record too long" (er also den listen XXXX ssl ignoriert). Neustart des nginx und Plesk etc haben leider nichts am Problem geändert.
Laut Dokumentation von Plesk sollen in die Zusätzlichen nginx direktiven genau die gleichen Einträge wie man Sie in der nginx.conf machen würde. Also verstehe ich meinen Fehler im Moment nicht.
Theoretisch kann ich das ganze auch über den Docker Proxy lösen, der Spinnt aber leider bei 2 Containern bzw scheint der Login bei 2 Containern nicht zu korrekt zu funktionieren.

Hat jemand eine Idee wo mein Fehler ist?.
Beispiel für die direktiven wie ich Sie eingetragen habe (Daten abgeändert):
listen 1234 ssl;
listen [::]:1234 ssl;
server_name domain.de www.domain.de;
ssl_certificate /opt/cert/certificate_server.crt;
ssl_certificate_key /opt/cert/privatkey.key;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

habe auch diese Config versucht:
server_name domain.de;
listen 1234 ssl;
location test {
proxy_pass http://www.domain:1234;
proxy_connect_timeout 159s;
proxy_send_timeout 600;
proxy_read_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_http_version 1.1;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
ssl_certificate /opt/cert/certificate_server.crt;
ssl_certificate_key /opt/cert/privatkey.key;
 
nexus said:
Nur am Rande (zu Plesk kann ich nichts sagen, da ich es nicht verwende):

Wenn du auf Sicherheit bedacht bist, dann solltest du auch im Auge behalten, daß das von dir verwendete System seit 06.07.2020 End Of Life ist und hier zeitnah ein Systemupgrade durchführen.
Click to expand...

Ja das ist mir bekannt. Das Problem ist das PLESK bis zum 2.7.2020 nicht mit Debian 10 Kompatibel war und auch immer noch diverse Features fehlen (u.a diverse PHP Interpreter) und ein Upgrade von 9 auf 10 derzeit auch noch nicht möglich ist (für Plesk).
Deshalb habe ich micht dazu Entschieden erstmal alles zum laufen zu bringen und dann über Neujahr, wenn keiner das System braucht, das System dann entsprechend anzupassen (in der Hoffung das Plesk den Migrator bis dahin fertig hat).


Kurzes Update zum Problem:
Nach einem Hilfreichen Hinweis habe ich die Cofig jetzt soweit für einen proxy_pass. War meine 2. Config von oben (die längere), ich musste lediglich den listen rausnehmen und die Certs. Soweit ich alles gut, jetzt hängt es nurnoch am aufruf des Logins.
Der Proxy gibt natürlich die uri /test/ weiter, die es aber in dem Contiainer natürlich nicht gibt. Beim Aufruf des Ports 1234 wird "/index.html#!/login" aufgerufen, was ich aber nicht direkt als Proxy Uri weitergeben kann. Habe einen rewrite versucht (der /test/ durch /index.html#!/login ersetzt) das ding zu encoden etc.
Sollte hier nochmal jemand einen Geistesblitz haben, wäre das toll. Sonst muss ich im Container die index.html in einen /test/ Ordner packen und schauen ob das funktioniert, wobei glaube ich einige referenzen statisch sind im Code der Anwendung, das muss ich Prüfen.
 
JustARandomDude said:
Ja das ist mir bekannt. Das Problem ist das PLESK bis zum 2.7.2020 nicht mit Debian 10 Kompatibel war und auch immer noch diverse Features fehlen (u.a diverse PHP Interpreter) und ein Upgrade von 9 auf 10 derzeit auch noch nicht möglich ist (für Plesk).
Click to expand...
Das ist ein bitteres Armutszeugnis für solch ein überteuertes Panel. Vor allem wenn man bedenkt, daß Debian 10 im Juli 2019 released wurde...o_O

JustARandomDude said:
Deshalb habe ich micht dazu Entschieden erstmal alles zum laufen zu bringen und dann über Neujahr, wenn keiner das System braucht, das System dann entsprechend anzupassen (in der Hoffung das Plesk den Migrator bis dahin fertig hat).
Click to expand...
Zumindest werden über den LTS-Zweig von Debian 9 noch für einige Pakte Patches und Fixes zurückportiert.
 
nexus said:
Das ist ein bitteres Armutszeugnis für solch ein überteuertes Panel. Vor allem wenn man bedenkt, daß Debian 10 im Juli 2019 released wurde...o_O

Ich habe den genauen Grund irgendwo mal gelesen, Der Grund war glaube ich das irgendeine wichtige Kernel Funktion umgebaut wurde oder gestrichen wurde, welche eine neue Architektur der Software von Nöten gemacht hat.
Aber ja, das war schon extrem blöd.

Zumindest werden über den LTS-Zweig von Debian 9 noch für einige Pakte Patches und Fixes zurückportiert.
Click to expand...
 
GwenDragon said:
Och, Obsidian läuft schon unter Debian 10.

Zu Debian 9 kann ich heute nicht mehr weiter helfen.
Click to expand...

Wie gesagt, das Obsidian jetzt seit Anfang Juli bereitsteht weiß ich. Jedoch Kostet das umziehen viel Zeit, da ein Upgrade von Plesk unter 9 auf Plesk unter 10 noch nicht Unterstütz wird :). Diese Zeit habe ich im Moment eben nicht, deshalb konzentriere ich mich darauf erstmal den Fehler zu beheben und dann zu schauen
 
You must log in or register to reply here.
Back
Top