Zugriff von extern / WSS

[saegefisch]

Hi André,
ich wusste, ich erinnerte mich dezent, es gelesen zu haben, aber in meiner optimistischen Hoffnung, dass es doch mit einem Kniff geht, habe ich wohl nach den falschen Begriffen gesucht. Danke Dir für den Link.
Damit komme ich zu diesem (für mich abschließenden) Fazit um Thema SSL und externem Zugriff auf edomi:

• edomi bleibt bis auf weiteres im LAN ohne SSL
• Alle anderen webbasierten Serverdienste im LAN laufen per https mit Zertifikaten meiner eigenen CA, außer edomi. In allen Browsern muss auch nur ein CA-Zertifikat importiert. Vielleicht ging es nur mir so: In all' den Tutorials zu SSL wird am Anfang immer alles "schön convinient" mit CA begonnen - und hat dann auf jedem Server eine eigene CA. Bis man als SSL-Theoretiker auf den Trichter kommt, dass sinnvoll ist und auch geht (das Thema ist für Neulinge durchaus komplex), nur eine CA-Instanz zentral zu haben und dort alle Zertifikate für alle Server zentral zu erzeugen, habe ich meist nicht gelesen.
• Also als Tipp aus meiner Lernkurve: Falls es anderen auch so geht, wie mir und unsicher wegen SSL, Zertifikaten, CA und dem ganzen Gedöns sind: Läuft geschmeidig und man kann zentral wunderbar und in Minuten neue Zertifkate erzeugen (neue Dienste oder wenn man per DNS von IP auf Namen umsteigt), andere widerrufen,... und braucht nur ein Zertifikat in den Browsern importieren für alle Dienste im LAN.
• Zugriff per Reverse Proxy und Client Certificates halte ich für eine hinreichend sicher Lösung, die mir keine Sorgen macht, ein Loch aufzureißen. Im Umkehrschuss gilt für edomi aber umso mehr, als man es sonst ohnhin tun sollte: Andere PW nutzen, als für andere Dienste, damit im Fall des Falls ein Sniffer für andere Dienste und Logins nutzlos ist und "nur" in edomi sein Unwesen treiben kann - was schon doof genug sein kann.
• Externer Zugriff per Reverse Proxy auf edomi geht bislang nur so: WWW -- https --> RevProxy -- http --> edomi - aber das geht auf jeden Fall ganz wunderbar und darum ging es ja hier im Thread. Man könnte übrigens unterscheiden und admin per https aufrufen und nur die Visu per http - damit wäre zumindest das amdin-PW auch nicht sniffbar (wer also echt Bedenken dazu hat)
• Auf andere Dienste im LAN bei Bedarf WWW -- https --> RevProxy -- https --> whatever (nextcloud, Foto-gallery,... you name it...)

Wegen Chrome und Zertifikaten: Bei mir komme ich bei den erweiterten Einstellungen direkt zu einem PopUp der zentralen Windows-Zertifikats-Verwaltung. Chrome zeigt die Zertifikate ja auch als gültig an, wenn man in die Details geht. Aber im Aufruf bleibt es bei "Nicht sicher" und "ungültig"... :-/

[coliflower]

• Alle anderen webbasierten Serverdienste im LAN laufen per https mit Zertifikaten meiner eigenen CA, außer edomi. In allen Browsern muss auch nur ein CA-Zertifikat importiert. Vielleicht ging es nur mir so: In all' den Tutorials zu SSL wird am Anfang immer alles "schön convinient" mit CA begonnen - und hat dann auf jedem Server eine eigene CA. Bis man als SSL-Theoretiker auf den Trichter kommt, dass sinnvoll ist und auch geht (das Thema ist für Neulinge durchaus komplex), nur eine CA-Instanz zentral zu haben und dort alle Zertifikate für alle Server zentral zu erzeugen, habe ich meist nicht gelesen.
• Also als Tipp aus meiner Lernkurve: Falls es anderen auch so geht, wie mir und unsicher wegen SSL, Zertifikaten, CA und dem ganzen Gedöns sind: Läuft geschmeidig und man kann zentral wunderbar und in Minuten neue Zertifkate erzeugen (neue Dienste oder wenn man per DNS von IP auf Namen umsteigt), andere widerrufen,... und braucht nur ein Zertifikat in den Browsern importieren für alle Dienste im LAN.

Hallo Carsten,
so ein Tutorial für Newbies wäre jetzt, solange noch alles frisch in deiner Erinnerung ist, cool

[saegefisch]

Du Schelm... klar, gern...muss den Client Certifactes-Teil in meinem Wiki noch fertig machen, dann mach' ich ein PDF draus und lad's hoch

[EinAnfaenger]

Wegen Chrome und Zertifikaten: Bei mir komme ich bei den erweiterten Einstellungen direkt zu einem PopUp der zentralen Windows-Zertifikats-Verwaltung. Chrome zeigt die Zertifikate ja auch als gültig an, wenn man in die Details geht. Aber im Aufruf bleibt es bei "Nicht sicher" und "ungültig"... :-/

Der Dialog mit den Details ist ein Windows-Dialog und der ist ist auch ohne Subject Alternative Name zufrieden. Chrome will das Feld aber seit einiger Zeit (1 Jahr oder so?) belegt haben, sonst kommt eben eine Fehlermeldung.

Womit erzeugst Du denn Deine Zertifikate?

[saegefisch]

Ah, das ergibt Sinn, danke!
Werde (mit openssl) dann mal an meiner openssl.cnf adjustieren und SAN einbauen. Bin dabei auch gleich hoffnungsvoll auf eine mögliche Antwort auf meine jüngste Frage gestoßen: hat hoffentlich auch den positiven Nebeneffekt, dass man ein Zertifikat für mehrere Namen vergeben kann - ich hoffe mal, dann IP und host name in einem Zertifikat unterbringen zu können und es sollte dann egal sein, ob ich aufgelöst oder per name zugreife. In meiner derzeitigen Lösung geht immer nur das eine oder andere.

Nachtrag: wäre natürlich besser, die alternativen Namen könnte man bei der Erstellung des CSR einfach abfragen (wie den CommonName) und nicht in der cfn verdrahten... wie könnte das wohl gehen...? kann man für das CSR vielleicht alternative Namen als Argument mit geben?

Nachtrag 2: hier liesst man ganz unten bei BUGS "The current prompting is not very friendly. It doesn't allow you to confirm what you've just entered. Other things like extensions in certificate requests are statically defined in the configuration file. Some of these: like an email address in subjectAltName should be input by the user." Das stimmt nicht so positiv dazu; dann müsste man für jeden CSR erst die openssl-cnf anpassen...auf diversen Seite gibt es aber bereits Aufrufe mit Argumenten - sieht etwas hölzern aus...

Nachtrag 3: Info z.B. hier. Trotz der Anpassung in der cnf liefert mir Chrome die Warnung. CSR erstellt mit CommonName = 192.168.30.28

[ req ]
[...]
req_extensions = v3_req # The extensions to add to a certificate reques
[...]
[ v3_req ] # Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = DS2
DNS.2 = DS2.int
IP.1 = 192.168.30.28

Erst einmal aber Schritt für Schritt: Erst cnf-Datei angepasst (siehe oben)
Dann key: sudo openssl genrsa -out /etc/ssl/meineca/private/serverkey.192.168.30.28.pem 4096
Dann CSR: sudo openssl req -new -key /etc/ssl/meineca/private/serverkey.192.168.30.28.pem -out /etc/ssl/meineca/csr.192.168.30.28.pem -nodes
Prüfung: sudo openssl req -noout -text -in /etc/ssl/meineca/csr.192.168.30.28.pem | grep DNS zeigt mir im CSR beide DNS und die IP an.
Signieren mit: sudo openssl ca -in /etc/ssl/meineca/csr.192.168.30.28.pem -notext -out /etc/ssl/meineca/certs/servercert.192.168.30.28.pem schon hier werden mir die alternativen DNS nicht gezeigt
Prüfung: sudo openssl x509 -text -in /etc/ssl/meineca/certs/servercert.192.168.30.28.pem -noout zeigt mir im CRT nicht die alternativen Adressen an - das dürfte falsch sein und Ursache sein, dass es noch nicht geht...beim Signieren aus dem CSR zum CRT... jemand eine Idee, warum? Die CA muss wohl kaum noch mal erzeugt werden, oder?

[jonofe]

Ich setze bei mir easy-rsa ein. Damit war es echt einfach:

Mit diesem Befehl generiere ich ein neues SSL Zertifikat für einen Server:

./pkitool --server servername.domain.tld

Danach habe ich CRT, CSR und KEY file im keys Folder. Das kopiere ich dann auf den Server und es funktioniert auch in Chrome.
Ich vermute easy-rsa kapselt hier die Komplexität von openssl ganz gut.

[saegefisch]

es gibt auch für openssl wohl scripte, aber ich wollte es als Neuling im Thema in Gänze und seinen Abhängigkeiten begreifen... heute Mittag fühlte es sich auch noch so an jetzt eher

Hast Du den auch SAN hin bekommen, also ein Zertifikat, dass in einem Serverdienst den Zugriff per IP und host_name erlaubt?

[saegefisch]

es fehlt - warum auch immer - beim Signieren ein Argument. Ich nahm an, dass es in der cnf bereits verlinkt und damit aktiv sein müsste: -extensions v3_req. Das signieren erfolgt dann also mit

sudo openssl ca -extensions v3_req -in /etc/ssl/meineca/csr.192.168.30.28.pem -notext -out /etc/ssl/meineca/certs/servercert.192.168.30.28.pem

Damit hat man auch im Chrome ein grünes Schloss und in allen Browsern erlaubt das Zertifikat die Nutzung per IP oder host name. Das ist sehr charmant...
EinAnfaenger : Danke Thomas für Deinen Hinweis - und dem "Kollateralgewinn" durch SAN - sehr fein...

[coliflower]

SAN

Ich vermute, Folgendes kennst du schon ...
https://blog.pki.dfn.de/2015/12/open...amen-erzeugen/

[saegefisch]

ja... und geht ja auch schon... den Hinweis zu -extension fand ich aber hier
Muss jetzt noch verschieden Varianten versuchen und in meinem Wiki notieren - aus dem erzeueg ich dann das PDF...

[phili]

Hallo zusammen,
ich bin an dem Thema auch mal wieder dran und bekomme es ums Verrecken nicht hin:

• Proxy ist bei mir ein apache
• admin-Zugang funktioniert
• Login-Seite für die Visu erscheint und Anmeldedaten werden akzeptiert, dann bleibt es aber bei dem rotumkreiste edomi-Logo

Wer kann was mit der Fehlermeldung anfangen? Was fehlt bei mir noch?

[Mon Feb 12 20:31:47.665113 2018] [ssl:info] [pid 10683] [client ::1:47423] AH02008: SSL library error 1 in handshake (server edomi.meinserver.de:443)
[Mon Feb 12 20:31:47.665197 2018] [ssl:info] [pid 10683] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not SSL to HTTPS port!?

Hier der gesamte Fehlerlog:

[Mon Feb 12 20:31:30.638464 2018] [proxy:debug] [pid 10688] proxy_util.c(1771): AH00925: initializing worker ws://192.168.28.8:8080/ shared
[Mon Feb 12 20:31:30.638597 2018] [proxy:debug] [pid 10688] proxy_util.c(1813): AH00927: initializing worker ws://192.168.28.8:8080/ local
[Mon Feb 12 20:31:30.638682 2018] [proxy:debug] [pid 10688] proxy_util.c(1864): AH00931: initialized single connection worker in child 10688 for (192.168.28.8)
[Mon Feb 12 20:31:39.664783 2018] [proxy:debug] [pid 10689] proxy_util.c(1771): AH00925: initializing worker ws://192.168.28.8:8080/ shared
[Mon Feb 12 20:31:39.664915 2018] [proxy:debug] [pid 10689] proxy_util.c(1813): AH00927: initializing worker ws://192.168.28.8:8080/ local
[Mon Feb 12 20:31:39.664997 2018] [proxy:debug] [pid 10689] proxy_util.c(1864): AH00931: initialized single connection worker in child 10689 for (192.168.28.8)
[Mon Feb 12 20:31:47.664385 2018] [ssl:info] [pid 10683] [client ::1:47423] AH01964: Connection to child 0 established (server edomi.meinserver.de:443)
[Mon Feb 12 20:31:47.665113 2018] [ssl:info] [pid 10683] [client ::1:47423] AH02008: SSL library error 1 in handshake (server edomi.meinserver.de:443)
[Mon Feb 12 20:31:47.665197 2018] [ssl:info] [pid 10683] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not SSL to HTTPS port!?
[Mon Feb 12 20:31:47.665270 2018] [ssl:info] [pid 10683] [client ::1:47423] AH01998: Connection closed to child 0 with abortive shutdown (server edomi.meinserver.de:443)
[Mon Feb 12 20:32:01.679408 2018] [ssl:info] [pid 10688] [client ::1:47426] AH01964: Connection to child 2 established (server edomi.meinserver.de:443)
[Mon Feb 12 20:32:01.680626 2018] [ssl:info] [pid 10688] [client ::1:47426] AH02008: SSL library error 1 in handshake (server edomi.meinserver.de:443)
[Mon Feb 12 20:32:01.680741 2018] [ssl:info] [pid 10688] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not
SL to HTTPS port!?
[Mon Feb 12 20:32:01.680773 2018] [ssl:info] [pid 10688] [client ::1:47426] AH01998: Connection closed to child 2 with abortive shutdown (server edomi.meinserver.de:443)

Configfile wie folgt (Standard aus diesem Thread):

<VirtualHost *:443>
    ServerAdmin phili@meinserver.de
    ServerName edomi.meinserver.de
    ProxyPreserveHost On

    DocumentRoot /var/www/html

    # Turn on SSL
        SSLEngine on
        SSLProxyEngine On
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off

        #   A self-signed (snakeoil) certificate can be created by
        # installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only
        # the
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/letsencrypt/live/meinserver.de/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/meinserver.de/privkey.pem

    # Configure the proxy

    ErrorLog ${APACHE_LOG_DIR}/meinserver/edomi_error_https.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
#    LogLevel warn
#    LogLevel info
    LogLevel debug

    CustomLog ${APACHE_LOG_DIR}/meinserver/edomi_access.log combined

    ProxyPass / http://192.168.28.8/
    ProxyPassReverse / http://192.168.28.8/

</VirtualHost>

<VirtualHost *:8080>
        ServerAdmin phili@meinserver.de
        ServerName edomi.meinserver.de
#       ProxyPreserveHost On

        DocumentRoot /var/www/html

    # Turn on SSL
        SSLEngine on
#       SSLProxyEngine On
#        SSLProxyVerify none
#        SSLProxyCheckPeerCN off
#        SSLProxyCheckPeerName off
#        SSLProxyCheckPeerExpire off

        #   A self-signed (snakeoil) certificate can be created by
        # installing
        #   the ssl-cert package. See
        #   /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
        #   If both key and certificate are stored in the same file, only
        # the
        #   SSLCertificateFile directive is needed.
        SSLCertificateFile    /etc/letsencrypt/live/meinserver.de/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/meinserver.de/privkey.pem

        # Configure the proxy

        ErrorLog ${APACHE_LOG_DIR}/meinserver/edomi_error_wss.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
#       LogLevel info
        LogLevel debug

        CustomLog ${APACHE_LOG_DIR}/meinserver/edomi_access.log combined

        ProxyPass / ws://192.168.28.8:8080/
        ProxyPassReverse / ws://192.168.28.8:8080/

</VirtualHost>

[saegefisch]

Hallo Carsten,
so ein Tutorial für Newbies wäre jetzt, solange noch alles frisch in deiner Erinnerung ist, cool

Hi Dariusz,
wer so nett fragt...den bestraf' ich mit ein paar Zeilen nicht unter 10 Seiten...

Anbei ein paar Zeilen zu meinen Erkenntnissen zum Gesamtthema SSL / https / CA / Zertifikate für Server im LAN einerseits und Clients eines Reverse Proxy. Möge es Dir und anderen vielleicht helfen, das Thema Reverse Proxy (weiter oben hier im Thread) und SSL etwas gesamtheitlicher zu begreifen und lösen zu können. Vielleicht habe ich auch falsche Erkenntnisse gesammelt und hier zum Besten gegeben - aber Ich bin jezt ganz zufrieden, da die CC wie auch die zentralen SC wunderbar funktionieren und sehr ähnlich ticken. Letztlich hat unsereins ja nur 1-2 handvoll Server und vielleicht ähnlich viele Anwender mit CC und das soll einfach laufen und einfach sein, wenn man MOnate später mal wieder dran muss.

Sollte ich irgendwo falsch liegen, dann gerne Rückmeldung hier im Threat.

VG, Carsten

[saegefisch]

Und gleich noch eine Frage: Hat jemand im NGINX schon mal getrennte Client Certicates (CC) für unterschiedliche Anwendungen eingerichtet, zu denen der Reverse Proxy weiter leitet? Also z.B: Ein Satz CC nur für edomi und ganz andere CC für ein wiki oder nextcloud.

Wegen der getrennten CRL wird es wohl auf jeden Fall getrennte CA für jede Anwendung geben müssen - was ja erst einmal kein Problem ist, ich bin ja jetzt im Thema... Die Frage ist: Wie sag ich's NGINX? Auf den ersten Blick geht es nur pro "listen" und nicht pro "location"... habe ich falsch geschaut oder hat jemanden einen Kniff?

Danke!

[starwarsfan]

Hi,

Vielleicht hilft es ja: https://serverfault.com/questions/84...s-verification

[coliflower]

Danke Carsten :-) !!