Apache, PHP... Wordpress Installation

Bob.Dig · 19. August 2019

Vorab, ich bin Laie, der aus Spaß an der Freude zu hause eine Website hosten will bzw. selbiges ausprobieren möchte.

Vorgeschichte:
Ich habe dazu auf einen virtuellen Ubuntu-Server Wordpress installiert, weil das angeblich so viele nutzen, und es hat auch funktioniert. Wenn ich nun auf diesen Server über HAProxy (pfSense) mit SSL-Offloading zugegriffen habe fehlten aber immer Teile der Demo-Website (Blog), also Hintergründe, Formatierungen etc. Es war fast nur reiner Text, sehr ärgerlich.

Da ich ohnehin nicht einen weiteren Server hosten wollte, habe ich erneut eine Installation vorgenommen, diesmal auf meinen virtuellen Ubuntu-Server, der ohnehin immer läuft und meine Nexctcloud (NC) hostet, mit LE-Cert. Ich habe nun auch wieder HAProxy vorgeschaltet und nun funktioniert das Ganze, wobei jetzt auch das Backend SSL verschlüsselt. Wenn ich das deaktiviere gibt es wieder die unvollständige Website bzw. Blog von Wordpress. SSL auf dem Server funktioniert für Wordpress vermutlich deswegen, weil ich in Apache für Wordpress die bestehende NextcloudConfig kopiert habe. Habe nur die Ports und Domain geändert, da es vermutlich anders nicht geht auf der selben Maschine.

Woran ich mich jetzt am meisten störe und wobei man mir vielleicht behilflich sein kann, wenn ich lokal auf Wordpress zugreifen will, lande ich immer bei NC, egal welchen Port ich angebe. Entweder es kommt zu Fehlermeldungen von NC oder ich werde auf die NC weitergeleitet.

Wenn ich von außen, d.h. mittels der Datenverbindung meines Handys oder mittels eines VPN-Tunnels eines externen Anbieters, auf die entsprechende Domain zugreife, dann, und nur dann, geht es und das auch ohne Fehler. Wobei der selbe Rechner lokal nicht geht, auch nicht mit einem passenden lokalen DNS-Eintrag.

Es geht mir auch nicht um irgendwelche Zertifikatswarnungen sondern vielmehr um Redirects auf die NC, wo ich doch auf Wordpress wollte.

Für mich macht das keinen Sinn, dass ich lokal nicht auf meine Wordpress Installation zugreifen kann, wohl aber von extern. Es wird sicher mit der Nextcloud-Installation zu tun haben, welche ich als fertige Appliance heruntergeladen habe. Vielleicht hat aber wer eine Idee, an welchen Stellschrauben ich zu drehen habe, dass ein lokaler Zugriff auf Wordpress doch noch möglich ist. Es wird vermutlich irgendwie an Apache oder PHP liegen?

gaym0r · 19. August 2019

Bob.Dig schrieb:
Es wird vermutlich irgendwie an Apache oder PHP liegen?

Jup!
https://httpd.apache.org/docs/2.2/de/vhosts/
https://httpd.apache.org/docs/2.4/vhosts/examples.html

Falc410 · 19. August 2019

Also erstmal zu deinem SSL Problem - schau mal in den Konsolenoutput vom Browser (Entwicklertools), ich denke durch das HA ändert sich der Hostname und der Browser blockiert dann das nachladen von Bildern - oder was ich auch schon mal bei Wordpress hatte - die Bilder wollen über HTTP geladen werden (weil Wordpress falsch konfiguriert) und dann blockt der Browser das. Gemischt HTTPS und HTTP auf einer Seite geht nicht (mehr).

Und zum zweiten Teil: Das liegt an deiner Apache Konfiguration. Ein Webserver kann viele Domains unter derselben IP hosten, allerdings entscheidet dann der DNS Name auf welchen virtuellen Host / Webseite du geleitet wirst. Wenn du nur über die IP oder den Hostnamen vom Server drauf zugreift, dann landest du im Default Webserver. Wahrscheinlich hat deine NC als Virtual Host etwas wie *:443 eingetragen und ist somit der Default.

Davon abgesehen, scheinst du ja gar nicht so der Laie zu sein, die meisten Menschen kennen pfSense nichtmal. Trotzdem der Hinweis, wenn man ein Wordpress betreibt welches im Internet erreichbar ist, auch unbedingt regelmässig die Updates einspielen. Es kommen tagtäglich tausende von Angreifern die per Script automatisiert Schwachstellen ausnutzen - gerade in Dingen wie Wordpress. Es gibt Plugins die IPs Sperren und Updates automatisch machen. Auf jeden Fall einrichten.

Bob.Dig · 19. August 2019

Danke für deinen Beitrag.

Falc410 schrieb:
Also erstmal zu deinem SSL Problem - schau mal in den Konsolenoutput vom Browser (Entwicklertools), ich denke durch das HA ändert sich der Hostname und der Browser blockiert dann das nachladen von Bildern - oder was ich auch schon mal bei Wordpress hatte - die Bilder wollen über HTTP geladen werden (weil Wordpress falsch konfiguriert) und dann blockt der Browser das. Gemischt HTTPS und HTTP auf einer Seite geht nicht (mehr).

Das kann gut sein, ich habe nach einer möglichst einfachen Lösung gesucht und das scheint WP dann wohl doch nicht zu sein.

Falc410 schrieb:
Und zum zweiten Teil: Das liegt an deiner Apache Konfiguration. Ein Webserver kann viele Domains unter derselben IP hosten, allerdings entscheidet dann der DNS Name auf welchen virtuellen Host / Webseite du geleitet wirst. Wenn du nur über die IP oder den Hostnamen vom Server drauf zugreift, dann landest du im Default Webserver. Wahrscheinlich hat deine NC als Virtual Host etwas wie *:443 eingetragen und ist somit der Default.

Korrekt, wobei ich auch die Ports mit angegeben habe, weil ja zwei Webserver auf der selbem Maschine laufen oder ist das mit Apache OOTB möglich, zwei virtuelle Hosts, beide mit den standard Ports zu betreiben, dann bräuchte ich vermutlich garnicht mehr HAProxy? Aber selbst mit angepasstem lokalen DNS geht es leider nicht!

Falc410 schrieb:
Davon abgesehen, scheinst du ja gar nicht so der Laie zu sein, die meisten Menschen kennen pfSense nichtmal. Trotzdem der Hinweis, wenn man ein Wordpress betreibt welches im Internet erreichbar ist, auch unbedingt regelmässig die Updates einspielen. Es kommen tagtäglich tausende von Angreifern die per Script automatisiert Schwachstellen ausnutzen - gerade in Dingen wie Wordpress. Es gibt Plugins die IPs Sperren und Updates automatisch machen. Auf jeden Fall einrichten.

Hab schon gesehen, das wird kompliziert in Verbindung mit HAProxy, aber soweit bin ich noch nicht und vielleicht sollte ich auch nach einer anderen Lösung suchen als Wordpress.

Falc410 · 19. August 2019

Jedes Lösung sollte regelmässig gewartet werden wenn man es als Webserver betreibt. In Wordpress konnte man früher die Default Werte einstellen - da konnte man wählen zwischen HTTP und HTTPS (da wo man auch die URL angibt).
Wenn der virtuelle Host auf unterschiedlichen Ports läuft sollte das kein Problem sein - egal wie du drauf zugreifst, also ob per VPN oder woanders. Sicher, dass du die Ports auch im Browser dann mitangegeben hast?

Und Wordpress ist eine einfache Lösung für ein CMS. Wenn du keine Serverwaltungssoftwae wie Plesk nutzen möchtest (was bei den meisten virtuellen Server kostenlos dabei ist wenn man einen mietet) dann musst du dich in die Apache Konfig einlesen.

Wenn du noch mehr Hilfe von Experten brauchst dann kannst du deine vHost Konfigs auch hier posten (je nach Distribution irgendwo in /etc/apache2/sites-available/ oder /etc/httpd/... usw.)

Bob.Dig · 19. August 2019

Falc410 schrieb:
Wenn der virtuelle Host auf unterschiedlichen Ports läuft sollte das kein Problem sein - egal wie du drauf zugreifst, also ob per VPN oder woanders. Sicher, dass du die Ports auch im Browser dann mitangegeben hast?

Ja, das ist ja was ich nicht verstehen kann. Aber mit configs posten ist eine gute Idee, werde ich heute noch machen, Danke!

Ergänzung (19. August 2019)

nexctcloud.conf

Code:

<VirtualHost *:80>
    ServerName cloud.MyDomain.de
    Redirect / https://cloud.MyDomain.de
</VirtualHost>

<VirtualHost *:443>

    Header add Strict-Transport-Security: "max-age=15768000;includeSubdomains"
    SSLEngine on
    SSLCompression off
    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    SSLHonorCipherOrder on

### YOUR SERVER ADDRESS ###

    ServerAdmin admin@MyDomain.de
    ServerName cloud.MyDomain.de

### SETTINGS ###
    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php7.2-fpm.nextcloud.sock|fcgi://localhost"
    </FilesMatch>

    DocumentRoot /var/www/nextcloud

    <Directory /var/www/nextcloud>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
    Satisfy Any
    </Directory>

    <IfModule mod_dav.c>
    Dav off
    </IfModule>

    SetEnv HOME /var/www/nextcloud
    SetEnv HTTP_HOME /var/www/nextcloud

    # The following lines prevent .htaccess and .htpasswd files from being
    # viewed by Web clients.
    <Files ".ht*">
    Require all denied
    </Files>

    # Disable HTTP TRACE method.
    TraceEnable off
    # Disable HTTP TRACK method.
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACK
    RewriteRule .* - [R=405,L]

    # Avoid "Sabre\DAV\Exception\BadRequest: expected filesize XXXX got XXXX"
    <IfModule mod_reqtimeout.c>
    RequestReadTimeout body=0
    </IfModule>

### LOCATION OF CERT FILES ###

    SSLCertificateChainFile /etc/letsencrypt/live/MyDomain.de/chain.pem
    SSLCertificateFile /etc/letsencrypt/live/MyDomain.de/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/MyDomain.de/privkey.pem
    SSLOpenSSLConfCmd DHParameters /etc/letsencrypt/live/MyDomain.de/dhparam.pem

</VirtualHost>

wordpress.conf

Code:

<VirtualHost *:82>
    ServerName cloud.MyDomain.de
    Redirect / https://cloud.MyDomain.de
</VirtualHost>

<VirtualHost *:444>

    Header add Strict-Transport-Security: "max-age=15768000;includeSubdomains"
    SSLEngine on
    SSLCompression off
    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    SSLHonorCipherOrder on

### YOUR SERVER ADDRESS ###

    ServerAdmin admin@MyDomain.de
    ServerName blog.MyDomain.de

### SETTINGS ###
    #<FilesMatch "\.php$">
    #    SetHandler "proxy:unix:/run/php/php7.2-fpm.nextcloud.sock|fcgi://localhost"
    #</FilesMatch>

    DocumentRoot /var/www/wordpress

    <Directory /var/www/wordpress>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
    Satisfy Any
    </Directory>

    <IfModule mod_dav.c>
    Dav off
    </IfModule>

    SetEnv HOME /var/www/wordpress
    SetEnv HTTP_HOME /var/www/wordpress

    # The following lines prevent .htaccess and .htpasswd files from being
    # viewed by Web clients.
    <Files ".ht*">
    Require all denied
    </Files>

    # Disable HTTP TRACE method.
    TraceEnable off
    # Disable HTTP TRACK method.
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACK
    RewriteRule .* - [R=405,L]

    # Avoid "Sabre\DAV\Exception\BadRequest: expected filesize XXXX got XXXX"
    <IfModule mod_reqtimeout.c>
    RequestReadTimeout body=0
    </IfModule>

### LOCATION OF CERT FILES ###

    SSLCertificateChainFile /etc/letsencrypt/live/MyDomain.de/chain.pem
    SSLCertificateFile /etc/letsencrypt/live/MyDomain.de/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/MyDomain.de/privkey.pem
    SSLOpenSSLConfCmd DHParameters /etc/letsencrypt/live/MyDomain.de/dhparam.pem

</VirtualHost>

Vielleicht fällt ja jemandem was auf. Wie gesagt, warum gehen Zugriffe nur extern (WP) und nicht von intern (immer NC), trotz Angabe des Ports. Vermutlich eine Härtung der NC-Appliance oder einfacher Fehler?

Und was ich auch gerne wüsste, kann Apache2 nun zwei Server auf den selben Ports hosten? Als ich das getestet habe ging es nicht, wobei jetzt mit unterschiedlichen Ports geht es ja auch nicht, zumindest nicht von intern. Sprich, mein Test wurde vermutlich ad absurdum geführt. Auch einige Browsererweiterungen haben sich nachträglich als problematisch erwiesen. Na ja, aus Schaden wird man klug. 🙃

Ergänzung (19. August 2019)

Unabhängig davon, gibt es eine einfachere und sicherere Alternative zu Wordpress?

Falc410 · 19. August 2019

Du kannst unendlich viele virtuelle Hosts unter der selben IP / Port laufen lassen. Fast jeder Webserver liefert mehrere Webseiten aus. Wenn du irgendwo ein Webhosting buchst, dann teilst du dir den Webserver mit 1000 anderen Kunden ohne was davon zu merken.

Also, wie vermutet hast du einfach *:80 eingetragen. Und wenn jemand mit nem Browser auf die IP geht, egal ob Port 80 oder 82 wird er immer weitergeleitet nach https://cloud.MyDomain.de - das kann ja nicht funktionieren. Theoretisch sollte es gehen wenn du https://IP:444 eintippst, aber du hast HSTS aktiv - da wird der Browser das wahrscheinlich blocken wenn die Domain nicht passt.

Und alternative für wordpress - kommt drauf an was du machen möchtest.

Bob.Dig · 19. August 2019

Falc410 schrieb:
Theoretisch sollte es gehen wenn du https://IP:444 eintippst, aber du hast HSTS aktiv - da wird der Browser das wahrscheinlich blocken wenn die Domain nicht passt.

Wobei er eine Sicherheitsausnahme wollte, habe ich bestätigt und lande trotzdem auf der NC. Habe auch mal für WP ne nackte Config genommen, aber auch da gab es Probleme.

Kann ich HSTS nur für WP deaktivieren?

Ich werde, wenn ich wieder Zeit finde, also mal alles auf den selben Ports hosten, dann muss Apache also quasi OOTB als Reverse Proxy funktionieren. Muss das dann in eine Config oder kann das weiterhin in mehrere Configs aufgeteilt werden?

Zu den Alternativen, eigentlich nur eine Website hosten, einfach und sicher und kostenlos. 😃

Falc410 · 19. August 2019

Ja das kann man per host aktivieren / deaktivieren. Zumindest macht es das testen einfacher.

Was dir helfen könnte sind schon aliase: https://stackoverflow.com/questions...irtual-hosts-on-the-same-same-ipdiffrent-urls
Weil ServerName Based wird bei dir nicht gehen wenn es keine Domain dazu gibt (wobei du die lokal auf deinem rechner in der hosts datei verwalten könntest):
https://httpd.apache.org/docs/2.4/vhosts/name-based.html

Aber wie gesagt, im moment müsste es doch schon gehen wenn du https://ip:444 machst. Da sollte das richtige kommen.

Webseite hosten....aha. Du musst schon genauer was du machen willst. Wordpress ist ein Content Management System, du kannst auch selbst statische Webseiten hosten und diese komplett in HTML selber schreiben.

Bob.Dig · 19. August 2019

Eine Domain gibt es, hab ich nur aus der Config entfernt. Die Domain habe ich auch in meinen lokalen DNS (pfSense) eingetragen. Und https://ip:444 schmeißt mich auf die NC obwohl es ja über HAProxy funktioniert.
Den kann ich übrigens nicht lokal ansprechen oder ich bin zumindest noch nicht drauf gekommen wie. Hatte schon mal probiert den DNS-Eintrag auf das Gateway zu setzen, das ging auf jeden Fall nicht, um so HAProxy von lokal zu erreichen.

Falc410 · 19. August 2019

Ist eigentlich unmöglich, dein wwwroot ist ja ein anderes. Du hast schon ein Apache 2 reload oder besser restart mal gemacht? und sonst auch keine .htaccess im wordpress verzeichnis liegen die du von nc kopierth hast und die einen re-direct macht?

snaxilian · 19. August 2019

Teile & herrsche oder anders ausgedrückt: Entwirre dein Setup und mache eins nach dem anderen, erleichtert die Fehlersuche ungemein

Ja, Apache kann mehrere Webseiten unter unterschiedlichen DNS-Namen hosten, die alle auf dem selben Server mit einer IP und dem gleichen Port liegen. Du kannst also https://mail.domain.tdl > Webmailer und https://cloud.domain.tld > Nextcloud und https://blog.domain.tld > Wordpress usw. Zauberwort sind vhosts und Beispiele wurden schon verlinkt.
Den HAProxy brauchst daher nicht wirklich.
Des Weiteren schreibst du, du hast NC als Appliance installiert. Schlechte Idee in deinem Anwendungsfall. Diese ganzen "schlüsselfertigen" Appliances setzen idR voraus, dass neben ihnen nichts weiteres im System existiert oder funktionieren nicht mehr sauber, wenn man die Config so weit anpasst, dass noch andere Dienste nebenher laufen sollen. Auch lernst du so nicht wirklich etwas und die Installation von NC ist keine Raketenrechnik und relativ gut dokumentiert.

Bob.Dig · 19. August 2019

Falc410 schrieb:
Ist eigentlich unmöglich, dein wwwroot ist ja ein anderes. Du hast schon ein Apache 2 reload oder besser restart mal gemacht? und sonst auch keine .htaccess im wordpress verzeichnis liegen die du von nc kopierth hast und die einen re-direct macht?

Restart immer wenn ich irgendwas verändert habe. .htaccess sagt mir nix, habe nur die besagt Apache-config kopiert. Vielleicht ist das eine Härtung, aber global?

snaxilian · 19. August 2019

htaccess ist die eierlegende Wollmilchsau und kann sehr mächtig sein aber eben auch unzählige Fehler auslösen: https://www.ionos.de/digitalguide/hosting/hosting-technik/htaccess-tricks/

Bob.Dig · 19. August 2019

@snaxilian Die Beispiele hatte ich auch schon gesehen, aber hat halt nicht funktioniert in meinem Test. Werd ich mir aber nochmal anschauen. Und das mit dem Lernen ist so ne Sache, wenn man nicht vom Fach ist, ist es doch recht überwältigend irgendwann. 😜

Und ich vermute es ist "sicherer", wenn ich etwas an der gehärteten Appliance herumspiele als das ich was eigenes, völlig ungesichertes, auf die Beine stelle, was dann vielleicht funktioniert, aber wie lange. Daher frage ich lieber hier.

Generell schade ist, dass das SSL offloading mittels HAProxy anscheinend in der Praxis nicht läuft, siehe mein Wordpress Beispiel oder zumindest nicht automatisch. Hätte es nämlich lieber unverschlüsselt im Backend und Verschlüsselung nur durch HAProxy, aber das will ja auch nicht so recht...

Helge01 · 19. August 2019

Es wird nicht einfach werden dir zu helfen. Ich würde an deiner Stelle nicht alles auf einmal machen, sondern nach und nach.

Als erstes benötigst du:
3 Subdomains, z.B. www.example.com und example.com für den Webserver (Wordpress) und cloud.example.com für Nextcloud

ein Server SAN Zertifikat mit allen 3 Domains oder ein Wildcard Zertifikat

Grundsätzlich ist das Vorgehen über den HA-Proxy der pfSense schon ok, da es einige Vorteile hat. Du erstellst 2 SharedFrontends für http und https und anschließend die Frontends für Wordpress und Nextcloud.

Neuer Eintrag für SharedFrontend für http
Name: SharedFrontend-http
Status: aktiv
External address: WAN address (IPv4) Port 80 sonst keine weiteren Angaben!
Typ: http / https (offloading)
Default Backend: kein
Speichern

Anschließen speichern und einen neuen Eintrag für HTTP Frontend für den Webserver (Wordpress) erstellen.
~~Das lasse ich mal frei, da nicht klar ist, wie mit HTTP Anfragen zu verfahren ist. Sollen die zum Webserver durchgereicht werden, oder soll ein Redirect auf HTTPS erfolgen.~~

Es erfolgt ein Redirect von HTTP zu HTTPS und von example.com zu www.example.com

Neuer Eintrag für Frontend http Redirects
Name: Webserver-HTTP-HTTPS-Redirect
Status: Aktiv
Shared Frontend: Haken setzen
Primary frontend: SharedFronend-http - http

2 Einträge unter Access Control lists
Name: httpRedirectACL
Expression: Host starts with
Value: example.com

Name: httpACL
Expression: Host matches
Value: www.example.com

2 Einträge unter Aktionen
Redirect http://example.com zu https://www.example.com
Action: http-request redirect
Condition acl names: httpRedirectACL
rule: code 301 location https://www.%[hdr(host)]%[path]

Redirect http://www.example.com zu https://www.example.com
Action: http-request redirect
Condition acl names: httpACL
rule: code 301 location https://%[hdr(host)]%[path]

Default Backend: kein
Speichern
----------------------------------------------------------------------------------------------------------------------

Neuer Eintrag für SharedFrontend für https
Name: SharedFrontend-https
Status: aktiv
External address: WAN address (IPv4) Port 443 sonst keine weiteren Angaben!
Typ: http / https (offloading)
Default Backend: kein
SSL Offloading: das SAN / Wildcard Server Zertifikat auswählen und Haken bei:
Add ACL for certificate CommonName. (host header matches the "CN" of the certificate)
Add ACL for certificate Subject Alternative Names
Advanced ssl options (gilt nur für haproxy-devel Version, sonst muss der Cipher Eintrag angepasst werden)
alpn h2,http/1.1 ssl-min-ver TLSv1.2 ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
Speichern

Neuer Eintrag für Frontend https Webserver (Wordpress)
Name: Webserver-HTTPS
Shared Frontend: Haken setzen
Primary frontend: SharedFronend-https - http

2 Einträge unter Access Control lists
Name: WebserverSNI
Expression: Host starts with
Value: example.com

Name: WebserverSubSNI
Expression: Host matches
Value: www.example.com

Unter Aktionen folgende 2 Einträge erstellen:
Redirect https://example.com zu https://www.example.com
Action: http-request redirect
Condition acl names: WebserverSNI
rule: code 301 location https://www.%[hdr(host)]%[path]

Action: Use Backend
Condition acl names: WebserverSubSNI
backend: Backend-Webserver

Das Backend-Webserver muss zuvor noch unter Backend erstellt werden.
Name: Backend-Webserver
Server list
Mode: active
Name: Webserver
Forwardto: Address+Port
Address: IP-Adresse Ubuntu Server
Port: 8080 sonst keine weiteren Angaben! (Encrypt SSL no, SSL checks no)

Speichern, weiter geht es auf dem Ubuntu Server.

/etc/apache2/sites-enabled/webserver.conf

Code:

<VirtualHost *:8080>
        ServerAdmin webmaster@localhost
        ServerName www.example.com          # Deine Webserver Domain
        DocumentRoot /var/www/webserver/    # Pfad zu deiner Wordpress Installation

        <Directory /var/www/webserver/>     # Pfad zu deiner Wordpress Installation
                Options -Indexes
                AllowOverride All
        </Directory>
</VirtualHost>

/etc/apache2/ports.conf
Listen 8080

sudo systemctl restart apache2

In der wp-config.php von Wordpress unbedingt den Inhalt hinzufügen:

Code:

// If we're behind a proxy server and using HTTPS, we need to alert WordPress of that fact
// see also http://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
         $_SERVER['HTTPS'] = 'on';
}

Auf der pfSense noch zwei Firewall Regel am WAN Interface erstellen:

Erlauben Quelle: alle,
Ziel: WAN address
Port: 443

Erlauben Quelle: alle,
Ziel: WAN address
Port: 80

Nun sollte deine Webseite unter https://www.example.com oder https://example.com von intern und extern erreichbar sein, richtige Grundkonfiguration von Wordpress vorausgesetzt.

Wenn Bedarf ist, kann man noch den vollständigen Nexcloud Zweig im HA-Proxy durchgehen.

Bob.Dig · 19. August 2019

Erst mal danke Helge. Domain bzw. Sudomains und Wildcard-Cert sind vorhanden und auch in HAProxy eingestellt. Es läuft ja bereits über HAProxy, aber halt nicht lokal und wenn ohne Verschlüsselung auf dem Server selbst dann gab es außerdem unvollständige Seiten. Warum bei mir die Seiten unvollständig waren, ich werde mal schauen, ob deine detaillierte Anleitung da hilft. 👍
Dies scheint ja eine Wordpress-Konfigurationsproblem zu sein. Ich hab da selbst gar nichts eingestellt. Hatte gehofft alles über das Admin-Interface einstellen zu könne, aber das sah sehr aufgeräumt aus (wenig einzustellen) bzw. dass ich nichts einstellen müsste. Diverse SSL-PlugIns für Wordpress brachten ebenfalls keine Verbesserung beim gestrigen herumprobieren.

Ergänzung (19. August 2019)

Bin gestern beim stöbern noch auf diese HAProxy Regel gestoßen und habe diese mal eingepflegt, da zumindest die Nextcloud eh ein Redirect macht. Das war aber erst ganz zum Schluss, wo mich jegliche Hoffnung verlassen hat, kann also nicht ursächlich sein für irgendwas. 😉

Helge01 · 19. August 2019

Deine Einstellung im HA-Proxy sind falsch. Meine Anleitung lässt den Zugriff intern bzw. extern zu, aber grundsätzlich nur über den HA-Proxy per HTTPS. Dieser reicht die Anfragen unverschlüsselt an den Ubuntu Server weiter. Das direkte Aufrufen der Seite www.example.com:8080 über den Apache Ubuntu Server wird unter diesen Vorraussetzungen nicht ohne Fehlern funktionieren.

Möchtest du die Webseite ausschließlich von intern erreichen, dann macht der Umweg über den HA-Proxy keinen Sinn. Da wäre eine angepasste Virtual Hosts auf dem Apache einfacher.

Bob.Dig · 19. August 2019

@Helge01 Welche Einstellung meinst Du, das letztgepostete? Wie gesagt, das war noch nicht aktiv und soll wohl nur ein Redirect sein, getestet habe ich es noch nicht. Werde einen neuen Server aufsetzen ohne SSL und nach deiner Anleitung vorgehen und gucken ob es hilft mit meinem Wordpress-Problem, was die unvollständigen Seiten betrifft.
Dass eine lokale Verbindung mittels Port irgendwie immer umgeleitet wurde konnte ja noch niemand erklären. Das ist aber das andere Problem. Eins nach dem anderen.

Helge01 · 19. August 2019

Ich habe noch die Redirects ergänzt. Alles wird umgeleitet auf https://www.example.com.

Apache, PHP... Wordpress Installation

Captain

Captain

Vice Admiral

Captain

Vice Admiral

Captain

Vice Admiral

Captain

Vice Admiral

Captain

Vice Admiral

Admiral

Captain

Admiral

Captain

Rear Admiral

Captain

Rear Admiral

Captain

Rear Admiral

Ähnliche Themen