Zugriff von extern / WSS

[coliflower]

Damit habe ich ingesamt drei CA dafür in Verwendung: Let's enrypt (dyndns), CA für LAN-Server, CA für Client Certificates

Hallo Carsten,

in deiner Anleitung, Seite 1 schreibst du, dass du 3 CAs hast, meinst du damit 3 "Intermediate-Zertifizierungsinstanzen" die aus dem einzigen CA Root erzeugt werden oder tatsächlich drei CAs mit 3 CA Root Zertifikaten ?
Ein Intermediate-Zertifikat hat ja grundsätzlich die Aufgabe der "Teilung", damit wenn zB SSL-Zertifikate kompromittiert werden, die User-Zertifikate weiterhin gültig bleiben ...

Bildschirmfoto 2018-02-13 um 22.53.09.png
Bildschirmfoto 2018-02-13 um 21.54.34.png

[saegefisch]

Nach meinem Verständnis habe habe ich zwei selbst erstellte parallele(!) root-CA, je eines für Server Zertifikate (auf zentralem Linux-Server) und eines für Client Zertifikate (auf RevProxy). Im Browser wird's mir zweistufig angezeigt, root und Zertifikat, wüsste nicht woher und wofür ich intermediates bräuchte.
Darüber hinaus greife ich auf die dritte CA "Let's enrcypt" parallel zu - ob die jetzt root sind oder "über LE" noch ein root steht oder nicht...ist mir relativ egal...

Für meine CA sehe ich den Fall nicht, den ich kann jedes Zertifikat revoken/zurückziehen - im Kontext eines LANs eine überschaubare Zahl. Für meine Server Zertifikate halte ich das kompromittieren für ein überschaubares Risiko. Wen jemand bei einem Einbruch einen privaten Schlssel erbeutet, könnte ich das Zertifikat ja zurück ziehen (wenn ich es denn bemerken würde. Und dem Server einfach ein neues ausstellen und hoch laden. Das ist auch der Grund, warum man für jedem Server - obwohl technisch nicht nötig - ein eigenen Privaten Schlüssel erstellt.
Neudeutsch hieße das dann wohl in Richtung des Eindringlings "bätschi..sag ich da nur!"... Aber wie gesagt... ob man's denn merkt. Kritisch wäre der Einbruch in den NAS, denn wenn dort der private CA-Schlüssel liegt/läge, wär's halt doof, weil dann der Eindringling selber beliebige Zertifikate signieren könnte. Aber wenn man korrekterweise den CA-Schlüssel in einem Passwort-Safe ablegt(!!), sehe ich überhaupt kein Risiko.

Und selbst wenn, ich habe das Gefühl, das wäre was nicht sauber. Dann schlägt jetzt die Stunde meiner reproduzierbaren Lösung mit den fertigen cnf-File. Einfach komplett neue CA erstellen, und alle Server Zertifikate neu machen und hoch laden und cacert.pem in alle Clients importieren. Mit meinen WIki bräucht ich für 10 Server vielleicht 1h dafür. abgehakt, denn alle Einstellungen (inkl. SAN - nur CN muss man korrekt eingeben) sind schon voreingestellt, ist nur noch Fleißaufgabe für jeden Server die IP in den Kommandos zu ändern und auszuführen und zu verteilen. Genau das war der Grund für meinen Lösungsansatz. Ich könnte das sogar über ein Script komplett für meine Landschaft automatisieren.

Zu den Client Certifikaten gilt das gleiche.

Zu LE habe ich zu Deinem Szenario keine Vorstellung und nach 90 Tagen endet alles. im schlimmsten Fall neu aufsetzen und CERBOT nach Anleitung auf RevProxy - auch das ist <1h fertig.

Ist nicht bös' gemeint, aber mir erschient alles weitere jenseits " Zert. halt zurück ziehen oder CA und Z. neu aufsetzen" eher akademisch für den Anwendungsfall "LAN" - und für "die Welt da draußen" gibt es viel schlauere Leute als mich, die sich darum kümmern (sieh z.B. die kürzlich zurückgezogene Challenge bei LE)...

[coliflower]

Nach meinem Verständnis habe habe ich zwei selbst erstellte parallele(!) root-CA, je eines für Server Zertifikate (auf zentralem Linux-Server) und eines für Client Zertifikate (auf RevProxy). Im Browser wird's mir zweistufig angezeigt, root und Zertifikat, wüsste nicht woher und wofür ich intermediates bräuchte.

OK, vielleicht habe ich mich unglücklich ausgedrückt oder du möchtest tatsächlich zwei CAs haben um Server und Clients zu trennen ... Mein Hinweis war nur dahin, dass für eine Trennung nicht zwei CAs notwendig sind (die man auch einzeln pflegen muss), sondern dass es dafür die "Intermediate (Root) gibt", zB: Server und Clients.
Über Geschmack lässt sich nicht streiten ;-)

[saegefisch]

meine Intention, zwei getrennte zu machen, habe ich im PDF ja geschrieben: Es macht es schlicht einfacher und ich möchte Client C.und Server C. nicht mischen, weil ich es für möglich halte, das eine oder das andere mal neu machen zu wollen oder zu müssen - ohne den jeweils anderen "mit zu reißen". Da beide gleich ticken, ist es einfach. Weil der RevProxy nicht direkt im LAN ist, wäre es anderes eher aufwändiger, also kein Vorteil. Keep ist stupid simple....
Aber danke für Deinen HInweis, mit Deiner letzten Antwort verstehe ich Deine absolut konstruktive Frage jertzt auch...

[saegefisch]

Hallo Dariusz,

das ganze ist ja viel weniger aufwändig, als ich dachte und auch eine gemeinsame Root-CA für Server- und Client-Zertifikate ist recht einfach abbildbar, wenn man die openssl.cnf einmalig entsprechend aufbaut und bei den Zertifikaten dann definiert, mit welcher CA signiert werden soll. Weil es mir weiterhin einfacher erscheint für meine kleine Welt bleibe ich zwar bei meiner vielleicht etwas eher handwerklichen und weniger geschliffenen Lösung mit mehreren CAs, aber der Punkt geht eindeutig an Dich!

Daher noch mal danke für Deinen Einwand, zu dem ich anfangs zugegeben erst einmal den Kopf geschüttelt habe, mich aber grundsätzlich dann doch interessiert hat und zusammen mit meinem Wunsch nach unterschiedlichen Kreisen von Client-Zertifikaten und Yves hilfreichen Rückmeldung kam eine weitere Seite in meinem WIki heraus, die anbei als PDF zu finden ist und beides zusammen führt. Darin auch wieder weiterführende Links.

[mathschut]

Hallo,

ich möchte EDOMI hinter einem OpnSense Firewall (Pfsense) per reverse proxy veröffentlichen. Das ganze habe ich im Opnsense schon eingerichtet. Ich komme dann zwar auf die Webseite von Edomi zur Anmeldung, danach bleibt aber EDOMI Rot. Der Admin Bereich geht über den reverse proxy. Hat jemand eine Idee, was ich machen muss oder kann?

[saegefisch]

admin oder visu? Admin sollte auch ohne websocket gehen und ist damit erst einmal einfacher. Die Visu basiert auf websocket und braucht ein Upstrem bzw. Port 8080. Dazu sollten sich in diesem und anderen Threads zum Thema Reverse proxy (z.B. auch zum Suchwort Alexa) eine Reihe an gleichen Fragen und passenden Lösungen zu finden sein. Also: Erst einmal admin zum laufen bringen, dann per Stichwort websocket und Port 8080 für die visu Lösungen finden...

[mathschut]

Hallo, der Admin Bereich funktioniert. Das die normale Visu Seite nicht aufgeht, liegt es dann an der Firewall oder an EDOMI?

[saegefisch]

edomi nutzt für die visu das websocket-protokoll für die interaktive und schnell reaktive Oberfläche auf Port 8080. Das ist das Verfahren, mit dem edomi Dir eine Visu anbietet. Eine firewall sollte wenig probleme dabei damit haben, solange die üblichen Ports inkl. 8080 für beide Partner (edomi + Reverse proxy) erreichbar sind, Als dritter beteiligter muss der Reverse Proxy selber (meist wohl NGINX oder Apache) alle Port + Protokolle korrekt als Proxy auch weiterleiten - bei websocker mal flapsig mit "auch in beide Richtungen" ausgedrückt. Anders gesagt: Vermutlich fehlen Einstellungen im RevProxy, aber nichts in edomi und vermutlich nichts in der FW (sonst ginge auch admin schon nicht). Und damit verweise ich wieder auf die zahlreichen Lösungshinweise zu RevProxy un websocket hier im Thread und anderswo... Immerhin weißt Du jetzt, wo es vermutlich liegt und wonach Du schauen musst...

[benji]

Hi,

ich habe das allbeliebte Problem mit dem Websocket über reverse proxy. Ich habe im nginx folgende Konfiguration für den websocket hinterlegt:

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
}
upstream websocket {
 server <Edomi-IP>:8081;
}
#Websocket
server {
 listen <ReverseProxy-IP>:8081;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/<dyndns>/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/<dyndns>/privkey.pem;
 location / {
 proxy_connect_timeout 350; [COLOR=#FF0000]<------- Nur testweise[/COLOR]
 proxy_pass http://websocket;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 }
}

leider wird der websocket aber nicht zu Edomi verbunden. Websocket Port im Edomi ist 8081.
Portweiterleitung im Router ist die 443 und 8081 auf den Raspberry mit nginx.

wenn ich mit "netstat -nl" schaue stehen die Ports auch auf "Listen", Verbindung zum auf Adminseite funktioniert auch ohne Probleme.
Ich habe die gleiche Konfiguration auch bei mir zuhause laufen inkl. Visu. Jetzt wollte ich dies bei meinem Schwager auch so einrichten.

Fehlermeldung im nginx error.log ist folgende:

 [error] 3296#0: *83 upstream timed out (110: Connection timed out) while reading upstream, client: 212.18.XXX.XXX, server: , request: "GET / HTTP/1.1", upstream:  "http://<edomi-ip>:8081/", host: "<dyndns>:8081"

Hat eventuell noch jemand eine Idee wo ich schauen kann???

Gruß

[benji]

Niemand eine Idee??

Gruß

[saegefisch]

Meine Erfahrung dazu ist: Client Certifiacte (CC) auf https geht wunderbar, nicht aber auf websocket-port. Siehe auch dieses Thema dazu. Da ich seit Einrichtung des RevProxy immer wieder einen "hanshake"-Error im Log habe (Den ich zuvor noch nie hatte), liegt das wohlmöglich genau daran: Der WebSocket-Port ist ohne CC nicht gegen Portscans geschützt, die dann durch den RevProxy edomi erreichen. Derzeit alles nur ein Vermutung - siehe das ganze andere Thema. Ich würde eine CC-Lösung für den Websocket gleichfalls sehr begrüßen, war aber damit nicht erfolgreich. Und so habe ich immer wieder dieser Fehler im Log...

Du schreibst, dass es bei Dir so geht, nur bei Deinem Schwager nicht?

[benji]

Mein Reverse Proxy läuft „noch“ ohne CC. Alles von außen über https bis zum Reverse, ab da dann http zu Edomi. Die Visu funktioniert bei mir, websocket Fehler habe ich keine obwohl der Port 8080 bei mir direkt auf den Reverse Proxy weitergeleitet ist.

[saegefisch]

Im Beitrag des anderen Themas siehst Du auch den ganzen server-Block von mir für den WebSocket.

listen <ReverseProxy-IP>:8081;

Ich habe mir keinen IP vor dem Port, sonder nur

listen 8080 ssl;
listen [::]:8080 ssl;

Zudem hast als CC die LE-Zertifikate verwendet; ich denke nicht, dass das geht. Die dienen der Server Zertifizierung.
Für CC musst Du schon selber ein CA machen (siehe Beitrag #80).

[benji]

Hi,

wie gesagt, bei mir funktioniert die Konfiguration wie oben angegeben. Ich denke bei meinem Schwager liegt das Problem eher zwischen ReverseProxy und Edomi Websocket. Auch wegen dem Fehler "upstream timeout", ich weiß aber nicht genau warum.