The proxy server could not handle the request GET /alexa.

MiK77 · 27 Februar 2017, 22:08:06

Hallo,

ich wollte meinen Alexa-Zugriff wie empfohlen mittels Reverse-Proxy absichern. Beim Zugriff bekomme ich aber immer nur diesen Fehler:

Code Auswählen

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:

Code Auswählen

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

MiK77 · 28 Februar 2017, 11:50:01

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?

Jamo · 28 Februar 2017, 13:25:12

Ich hatte den gleichen Fehler, und habe bei mir in der Konfiguration des Apache Servers unter "SSLEngine on" und "SSLProxyEngine on" noch folgendes angegeben:

Code Auswählen

SSLProxyVerify off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

Damit läuft es dann bei mir.

Prof. Dr. Peter Henning · 28 Februar 2017, 16:35:37

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

MiK77 · 28 Februar 2017, 17:27:52

Also Folgendes in der /etc/apache2/sites-enabled/000-default.conf funktioniert jetzt bei mir, ist aber wohl keine saubere Lösung:

Code Auswählen


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

MiK77 · 28 Februar 2017, 18:24:25

Weiter Tests (jetzt mit Letsencrypt-Zertifikat) haben ergeben, dass nur diese beiden Parameter nötig sind:

Code Auswählen

 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.

justme1968 · 28 Februar 2017, 18:34:48

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.

MiK77 · 28 Februar 2017, 18:48:23

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.

justme1968 · 28 Februar 2017, 18:58:48

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'

MiK77 · 01 März 2017, 08:31:11

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?

Code Auswählen

<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>

Prof. Dr. Peter Henning · 01 März 2017, 08:35:58

Wie oft soll man das denn beantworten ?

LG

pah

MiK77 · 01 März 2017, 13:07:33

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.

cyvr1 · 01 März 2017, 13:59:37

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:

Code Auswählen


sudo a2ensite 001-fhem

Dadurch wird eine Verknüpfung (?) unter "sites-enabled" erstellt

Nach einem

Code Auswählen

sudo service apache2 restart
kann ich bzw. Alexa kann auf den fhem-Server zugreifen.

Prof. Dr. Peter Henning · 01 März 2017, 18:15:32

@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

MiK77 · 01 März 2017, 20:34:06

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.