Ankündigung

Einklappen
Keine Ankündigung bisher.

Zugriff von extern / WSS

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #76
    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
    Danke und LG, Dariusz
    GIRA | ENERTEX | MDT | MEANWELL | 24VDC LED | iBEMI | EDOMI | ETS5 | DS214+ | KNX/RS232-GW-ROTEL

    Kommentar


      #77
      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)...
      Zuletzt geändert von saegefisch; 14.02.2018, 02:08.

      Kommentar


        #78
        Zitat von saegefisch Beitrag anzeigen
        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 ;-)
        Danke und LG, Dariusz
        GIRA | ENERTEX | MDT | MEANWELL | 24VDC LED | iBEMI | EDOMI | ETS5 | DS214+ | KNX/RS232-GW-ROTEL

        Kommentar


          #79
          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...

          Kommentar


            #80
            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.
            Angehängte Dateien
            Zuletzt geändert von saegefisch; 15.02.2018, 14:59.

            Kommentar


              #81
              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?

              Kommentar


                #82
                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...

                Kommentar


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

                  Kommentar


                    #84
                    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...

                    Kommentar

                    Lädt...
                    X