Hallo,
ich wollte meinen Alexa-Zugriff wie empfohlen mittels Reverse-Proxy absichern. Beim Zugriff bekomme ich aber immer nur diesen Fehler:
Proxy Error
The proxy server could not handle the request GET /alexa.
Reason: Error during SSL Handshake with remote server
Meine Konfiguration sieht so aus:
<Location /alexa>
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/apache2/htpasswd"
Require valid-user
# ProxyPass http://localhost:8083/fhem
# ProxyPassReverse http://localhost:8083/fhem
ProxyPass https://localhost:3000/
ProxyPassReverse https://localhost:3000/
Order deny,allow
Allow from All
</Location>
Wenn ich die beiden auskommentierten Zeilen benutze, komme ich ohne Probleme auf die Weboberfläche. Aber wenn ich auf den node.js-Server auf Port 3000 zugreifen möchte, bekomme ich obigen Fehler. Der direkte Zugriff auf Port 3000 funktioniert und ergibt die erwartete Antwort.
Kann mir bitte jemand helfen? Webserver-Konfiguration ist leider nicht mein Spezialgebiet.
Das hier scheint das gleiche Problem zu sein:
https://forum.fhem.de/index.php/topic,60244.msg595467.html#msg595467
Leider gibt es dort auch keine Lösung bisher.
In welcher Datei soll man diese Konfiguration eigentlich am besten eintragen? Ich habe dazu schon mehrere verschiedene Beschreibungen gelesen. Ich habe es hier eingetragen:
/etc/apache2/sites-enabled/000-default.conf
Ist das korrekt?
Ich hatte den gleichen Fehler, und habe bei mir in der Konfiguration des Apache Servers unter "SSLEngine on" und "SSLProxyEngine on" noch folgendes angegeben:
SSLProxyVerify off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
Damit läuft es dann bei mir.
Leute, Leute,...
Ich verweise darauf, dass es gefährlich ist, mit der Konfiguration eines Apache-Servers herumzuspielen, wenn man nicht genau weiß, was man tut.
Erstens ist ein Wert "off" für das Attribut SSLProxyVerify nicht zulässig, siehe https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxyverify
Zweitens muss natürlich die Zertifikatserstellung auf dem Alexa-Fhem-Rechner ordnungsgemäß durchgeführt werden.
Drittens: Nein, da gehört NICHT in die default-conf. Sondern in eine separate Datei, (z.B. Dateiname fhem), die in das Verzeichnis /etc/apache2/conf.d gestellt wird.
LG
pah
Also Folgendes in der /etc/apache2/sites-enabled/000-default.conf funktioniert jetzt bei mir, ist aber wohl keine saubere Lösung:
<VirtualHost *:443>
ServerName xxx.de
SSLEngine on
SSLProxyEngine on
SSLCertificateKeyFile /etc/apache2/mycert/server.key
SSLCertificateFile /etc/apache2/mycert/server.crt
SSLProxyVerify off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
<Location /alexa>
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/apache2/htpasswd"
Require valid-user
ProxyPass https://localhost:3000/
ProxyPassReverse https://localhost:3000/
Order deny,allow
Allow from All
</Location>
</VirtualHost>
1. Frage:
Laut dieser oft verlinkten Anleitung https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension ist das die richtige Datei. Kam mir aber auch schon komisch vor. Gehört das jetzt alles nach /etc/apache2/conf.d/alexa? Oder teilweise in eine andere Datei?
2. Frage:
Wie kann ich herausfinden, woran die Zertifikatsprobleme liegen? Ich habe beim Erstellen des Zertifikats fast alle Felder leer gelassen. Vielleicht liegt es daran. Welche wären nötig, damit es keinen Fehler gibt?
Weiter Tests (jetzt mit Letsencrypt-Zertifikat) haben ergeben, dass nur diese beiden Parameter nötig sind:
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
Das hat wohl etwas damit zu tun, dass beim Zugriff auf "localhost" der Name nicht stimmt. Zumindest reime ich mir das so zusammen. Eine professionelle Erklärung ist aber trotzdem willkommen.
Damit ist ein Teil von Frage 2 beantwortet. Für eine Antwort auf Frage 1 wäre ich aber noch immer dankbar.
Zitat von: Prof. Dr. Peter Henning am 28 Februar 2017, 16:35:37
Ich verweise darauf, dass es gefährlich ist, mit der Konfiguration eines Apache-Servers herumzuspielen, wenn man nicht genau weiß, was man tut.
was genau beweist das der zusätzliche proxy nicht unbedingt sicherheit schafft wenn man nicht weiss was man tut. weder als vpn ersatz noch als zusatz vor alexa.
Ganz ohne Passwortschutz sollte man den node.js-Server aber wohl besser auch nicht betreiben. Deswegen wäre es schön, wenn jemand meine Fragen beantworten könnte.
was meinst du mit 'ohne passwortschutz' ?
der server ist gesichert durch die skill und oauth id. die beide vermutlich sicherer sind als ein einfaches password.
die oauth id wird zusätzlich live bei amazon gegengeprüft.
der server nimmt sich nur korrekt formatierte events laut amazon api zur verarbeitung an.
ich sage nicht das dies reicht oder das es nicht noch besser geht.
es ist aber alles andere als 'ohne schutz'
Danke für die Klarstellung. Das war mir so nicht bewusst.
Trotzdem wäre es für mich noch interessant zu wissen, in welchen Dateien ich die Konfiguration richtig unterbringen müsste. Oder gehört das wirklich alles in /etc/apache2/conf.d/alexa?
<VirtualHost *:443>
ServerName xxx.de
SSLEngine on
SSLProxyEngine on
SSLCertificateKeyFile /etc/apache2/mycert/server.key
SSLCertificateFile /etc/apache2/mycert/server.crt
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
<Location /alexa>
AuthType Basic
AuthName "Authentication Required"
AuthUserFile "/etc/apache2/htpasswd"
Require valid-user
ProxyPass https://localhost:3000/
ProxyPassReverse https://localhost:3000/
Order deny,allow
Allow from All
</Location>
</VirtualHost>
Wie oft soll man das denn beantworten ?
LG
pah
So oft, bis es eine leicht zu findende Stelle gibt, an der es richtig beschrieben ist.
Hier https://wiki.fhem.de/wiki/Alexa-Fhem#Absichern_des_Zugriffs wird zum Beispiel auf diese Anleitung verwiesen: https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension In der es definitiv falsch ist.
Meine Frage ist hauptsächlich, ob der allgemeine SSL-Teil auch in die spezielle Datei für den Alexa-Unterordner muss.
Hi MiK77,
kopiere am Besten den ganzen Block ab <VirtualHost *:443> in eine neue Datei. Je nachdem hast du einen Ordner conf.d oder auch nicht. Ich haben keinen auf meinem Raspi3 mit Jessie-Debian, dafür die Ordner "conf-available", "conf-enabled", "sites-available" und "sites-enabled". Die beiden letzteren gibt es auch auf dem Raspi2 mit Wheezy-Debian. Ich bin auch eher der Meinung, dass eine Konfiguration für eine Site/einen Port in den Ordner "sites-available" gehört. Unter conf.d finden sich Dateien für die grundsätzliche Konfiguration des Servers (Security Einstellungen, Character Set, lacalized error pages usw.).
Ich habe mir eine neue Datei "001-fhem.conf" unter "sites-available" erstellt und diese mit folgendem Befehl aktiviert:
sudo a2ensite 001-fhem
Dadurch wird eine Verknüpfung (?) unter "sites-enabled" erstellt
Nach einem
sudo service apache2 restart
kann ich bzw. Alexa kann auf den fhem-Server zugreifen.
@mik77: Falsch ist da gar nichts - das läuft so, wie dort beschrieben, und beim Editieren des Symlinks wird selbstverständlich die originale Datei (unter sites-available) geändert.
@cyvr1: Es ist vollkommen egal, ob in conf.d oder in sites-enabled als Symlink - beide Verzeichnisse werden auf die gleiche Weise bei Start von Apache eingelesen.
LG
pah
Mit "falsch" meinte ich, dass dort beschrieben wird, dass man die Änderungen in der default.conf vornehmen soll.
Dank der Hilfe von cyvr1 habe ich es jetzt aber alles erst einmal hinbekommen.
Ich hätte dazu aber noch eine weitere Frage:
Ich würde gerne alexa über einen anderen Port als 443 ansprechen. Wie müsste ich dies konfigurieren? Apache soll möglichst garnicht mehr auf 443 lauschen. Ich brauche den Port frei für etwas anderes.
Sicher kann man den Apache umkonfigurieren. Nur sollte man sich die Frage stellen ob das wirklich Sinn macht. Man hat nicht ohne Grund bestimmten Ports bestimmte Dienste zugewiesen. Wenn man dies nun ändert kann man das tun, aber man sollte sich der Risiken die sich dadurch ergeben bewusst sein. Denn für gewöhnlich laufen automatisierte Angriffe gegen Standardports und wenn nun da etwas anderes lauscht als ein robuster und durch Default Konfiguration ziemlich gut abgesicherter Apache kann das doch sehr interessante Nebeneffekt geben.
Kein Sorge. Auf 443 wird die meiste Zeit gar nichts laufen. Wie aufwendig ist es denn den Apache entsprechend umzukonfigurieren?
<5 Minuten. Wie steht in der Doku von Apache drin.