Zugriff von extern / WSS

[saegefisch]

Hallo allerseits,

ich mag das Thema aus zwei Gründen noch mal nach oben holen:
* Bei mir kann ich für den Websocket auf Port 8080 weiterhin im RevProxy (NGINX) keine Client Certificates aktivieren, weil dann die Visu nicht mehr geht. Bei benji scheint es ja zu funktionieren. Hat es noch jemand den WebSocket mit CC unter NGINX zum laufen gebracht?
Gibt es Einstellungen, die dafür nötig sind? Hintergrund: Ich bekomme in loser Folge weiter "Handshake"-Fehler, mit der Vermutung (siehe oben), dass dies daher kommt.
* Die auto-renewal von Let's encrypt (LE) schlägt leider immer fehl, weil meine server im RevProxy per Client Certificate abgesichert sind. Zur Zeit setze ich alle 90 Tage manuell den Parameter

 ssl_verify_client on;

auf off, stoße le-Renew manuell an und setze den CC-Parameter wieder auf on. Gibt es einen Weg, LE-Serverzertifikate automatisch zu erneuern ohne die CC kurz abzuschalten?

Auszug aus nginx.conf

 
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name edomi.<meinedomain>.de;

        ssl_client_certificate /etc/ssl/ca_int/cacert.pem;
        ssl_crl /etc/ssl/ca_int/private/ca.crl;
        ssl_verify_client on;    # on | off | optional | optional_no_ca

        location / {
                proxy_pass http://<edomi-IP>:80/;
        }

        # >> LOACTION CERTBOT --> Erforderlich für Let's encrypt Zertifikate (Anforderung/Erneuerung via certbot)
        location '/.well-known/acme-challenge' {
                default_type "text/plain";
                root /var/www/html;
        }
 }

Danke!

[s01iD]

Zu den Client Certificates kann ich nichts sagen. Let‘s Encrypt hingegen könntest Du per DNS-Challenge in Certbot automatisieren. Da müsstest Du im ersten Durchgang einen DNS-TXT-Eintrag setzen, danach läuft es automatisch und es braucht keinen direkten Zugriff auf das Acme-Verzeichnis. Das dürfte die einfachste Variante sein.

[EinAnfaenger]

Thema CC: Das liegt soweit ich weiß nicht an nginx (welcher die CC brav abfragt) sondern am Browser (welcher bei WS einfach kein CC sendet).

Lets Encrypt: Läuft der nginx auf einem eigenen Rechner? Dann mach doch Port 80 frei, nutze beim certbot --standalone und schalte über die --pre-hook, --post-hook via iptables den Port (80) frei und mach ihn wieder zu. Über den --renew-hook dann noch ein nginx reload und alles ist gut.

[benji]

Hi,

bei mir läuft nginx nur mit Servercertificat. Ich habe kein CC aktiviert.

Handshake error kommt bei mir ca. 1x im Monat.

[eric4980]

Hallo Zusammen,
ich habe bei mir nun Edomi 2.0 auf CentOS 7 am laufen.
Da ich hier im Geschäft keine Möglichkeit habe mich per VPN zu verbinden möchte ich gerne per https darauf zugreifen.
Leider scheitere ich bei der Einrichtung.
Was habe ich bereits geschafft:
1. Letsencrypt Zertifikat auf dem Edomi Server erstellt.
2. Einen Virtual Host für*443 erstellt.(Der Zugriff über https funktioniert auch, jedoch bleibt Edomi beim rot drehenden Rad stehen)

Hat jemand evtl. einen Tipp wo das Problem liegen könnte? Ich vermute es hat etwas mit der Websocket-Verbindung zu tun???

Vielen Dank für eure Hilfe
Eric

[Ing-Dom]

einfach mal den Thread lesen?

[GermanSniper]

Läuft den euer Reverse Proxy immer auf anderen Geräten oder kann ich den einfach auf dem edomi Server laufen lassen?

[givemeone]

Auf dem selben Server, auf dem auch edomi als docker Image läuft.

[michaeldamm2]

Also bei mir läuft das auf dem selben Server. ich muss nur nach einen Update immer eine Datei anpassen.

[jonofe]

Ich würde den Reverseproxy auf jeden Fall netzwerktechnisch vom EDOMI Server trennen. Idealerweise ist der Reverseproxy in der DMZ, d.h. zwischen ReverseProxy und EDOMI Server (internes Netz) befindet sich eine Firewall. Somit sind von außen nur Verbindungen zu ReverseProxy möglich und dieser ist dann berechtigt die Verbindung zu den internen Servern herzustellen.

Beim Einsatz von Docker oder Virtualisierung kann das natürlich auf derselben physikalischen Hardware passieren.

[gspsteve]

Möchte den Thread kurz nochmal ins Leben rufen.

Synology bitte mittlerweile die Möglichkeit komfortabel über die GUI einen ReverseProxy auf Basis von NGINX zu konfigurieren, welche Nachteile auch Sicherheitstechnisch ergeben sich dadurch!? Viele verwendet dies sicher auch zum durchschleifen an den Synology Webserver wieso also auch nicht zur Verbindung zu Edomi?

Habe diesen auch bereis konfiguriert und funktioniert bis dato sehr gut, falls jemanden die Konfig interessiert bitte um Info...

[s01iD]

Nutze ich auch so und die Nginx-Config sieht „normal“ aus. Lets Encrypt lässt sich auch direkt integrieren. Von daher: warum nicht.

[gspsteve]

Nutze ich auch so und die Nginx-Config sieht „normal“ aus. Lets Encrypt lässt sich auch direkt integrieren. Von daher: warum nicht.

Freut mich dass ich schon mal nicht der einzige bin :-)

Ich hatte anfangs lediglich probleme mit WebSocket wofür ich quasi nun einen eigenen RevProxy erstellt habe. Die Header Config in der Oberfläche für WebSocket brachte hier nichts. Sowie Port 443 kann ich auch nicht verwenden hab ein anderes konfiguriert nun muss ich dieses eben bei der URL mitgeben

s01iD wie hast du dies gelöst?

[s01iD]

Ich kann Edomi problemlos auf 443 laufen lassen, der Websocket läuft bei mir auf 8080. Konfiguration wie folgt siehe Anhang, die Zusatzheader gehören zum Websocket.

[gspsteve]

Ich kann Edomi problemlos auf 443 laufen lassen

Also wenn ich auf 443 umstelle kommt immer folgende Meldung, weiß jedoch noch nicht von welcher Applikation das Port verwendet wird, WebStation ist nicht installiert

2020-01-30 09_24_47-Schuh1 NAS und 10 weitere Seiten - Geschäftlich - Microsoft Edge.png

Zertifikat habe ich noch nicht eingebunden, steht jedoch noch auf der Liste. Hast du es somit so konfiguriert, dass sich nur Clients mit dem Zertifikat von extern auf EDOMI verbinden können!?