Differences

This shows you the differences between two versions of the page.

--- linux:apache2-https-webanwendungen-hinter-rp [2019/05/03 15:46] – created michael
+++ linux:apache2-https-webanwendungen-hinter-rp [2019/05/03 15:53] (current) – [Apache: SSL-Webanwendungen hinter Reverse Proxy] michael
@@ Line 2: / Line 2: @@
 Möchte man eine Webanwendung (Beispielsweise Wordpress, Durpal, Magento) hinter einen Apache als Reverse Proxy betreiben, so wird man spätestens bei der Verwendung von SSL vor ein Problem gestellt:
-Apache dient als SSL Backend, das heißt, dass das die Kommunikation zum Backend-Server unverschlüsselt erfolgt.
+Apache dient als SSL Backend, das heisst, dass das die Kommunikation zum Backend-Server unverschlüsselt erfolgt.
 Betreibt man nun eine Anwendung, die SSL erzwingt, wird man üblicherweise in einem Endlos-Loop landen.
-Die Ursache ist folgende:
+<WRAP center round important 100%>
-Während der Client über SSL (HTTPS://...) auf die Anwendung zugreift, sieht der Backender Server nur (HTTP://...) und wird versuchen einen Redirect auf (HTTPS://...) durchzuführen. Für den Client erfogt immer eine Weiterleitung von HTTPS://.. auf HTTPS://... während das Backend immer nur HTTP://.. sieht.
+''**Die Ursache ist folgende**:
+Während der Client über SSL (HTTPS://...) auf die Anwendung zugreift, sieht der Backend Server nur (HTTP://...) und wird versuchen einen Redirect auf (HTTPS://...) durchzuführen. Für den Client erfolgt immer eine Weiterleitung von HTTPS://.. auf HTTPS://... während das Backend immer nur HTTP://.. sieht.''
+</WRAP>
-===== VHost Konfigurieren =====
-Mit eine einzelnen Konfigurationszeile im SSL-Vhost auf dem Proxyserver kann man dieses Problem umgehen:
+===== Reverse Proxy Konfiguriguration =====
-In die SSL VHost konfiguration fügt man folgenden Zeile ein:
+Mit eine einzelnen Konfigurationszeile im SSL-RP auf dem Proxyserver kann man dieses Problem umgehen:
+In die SSL Reverse Proxy Konfiguration fügt man folgenden Zeile ein:
 <code>RequestHeader set X-Forwarded-Proto "https"</code>
@@ Line 18: / Line 21: @@
 Das sieht dann Beispielsweise so aus:
-<code>
+<sxh bash>
 <VirtualHost *:443>
@@ Line 36: / Line 39: @@
         .....
 </VirtualHost>
+</sxh>
-</code>
 Damit enthält der HTTP-Header die Information, dass es sich um einen SSL-Request handelt.
-===== 1. Möglichkeit: PHP-Anwendung anpassen =====
+===== Backend System Konfiguration =====
+<WRAP center box 100%>
+==== 1. Möglichkeit: PHP-Anwendung anpassen =====
 Manche PHP-Webanwendungen überprüfen nur den eigentlichen Protocol-Header mit $_SERVER['HTTPS']. Mit einer kleinen If-Anweisung kann man das Problem einfach umgehen:
@@ Line 53: / Line 59: @@
 Der Code prüft dann den vom Proxy veränderten/gesetzten HTTP-Header und setzt das HTTPS Global entsprechend.
 Dieses Snippet kann man zum Beispiel in die Datei ''wp-config.php'' einer Wordpress Installation einfügen, damit ein SSL-Backend funktioniert.
+</WRAP>
-===== 2. Möglichkeit: Backend Apache2 Konfiguration ergänzen =====
+----
+<WRAP center box 100%>
+==== 2. Möglichkeit: Apache2 Konfiguration ergänzen ====
 ''Diese Lösung soll falls möglich bevorzugt werden!'' Unter dem Servernamen, wird der Eintrag "SetEnvIf X-Forwarded-Proto "^https$" HTTPS=on" im entsprechenden VirtualHost oder der conf.d-Datei ergänzt.
@@ Line 77: / Line 87: @@
 Header set X-Frame-Options: "sameorigin"
 </sxh>
+</WRAP>
+----
+<WRAP center box 100%>
-===== 3. Möglichkeit: .htaccess konfigurieren =====
+==== 3. Möglichkeit: .htaccess konfigurieren ====
 Wenn man nicht im PHP-Code seiner Anwendung herumpfuschen will, dann kann man auch über die .htaccess Datei auf dem Backend-Server HTTPS vortäuschen.
@@ Line 89: / Line 101: @@
 </sxh>
-Im Zusammenspiel mit der VHost Direktive auf dem Proxy sollte es nun keine Problem mehr geben
+Im Zusammenspiel mit der Direktive auf dem Proxy sollte es nun keine Problem mehr geben
+</WRAP>