Apache, Problem mit mehreren VirtualHosts

[Vorticon X. (vorticon)]

Hallo zusammen,

Ich habe einen Apache-Server mit mehreren namensbasierten VirtualHosts. 
Die Zuordnung der Anfragen zu dem jeweiligen VirtualHost funktioniert 
nicht richtig. Die im Netz verfügbaren Informationen und Forumsbeiträge 
habe ich gelesen und berücksichtigt, ich konnte das Problem dennoch 
nicht lösen.

Kurze Zusammenfassung: ich habe eine Domain (domain.xyz) und zwei 
Subdomains (aaa.domain.xyz und www.domain.xyz).

Auf domain.xyz ist eine Website gehostet, die wie erwartet funktioniert.
Auf aaa.domain.xyz ist ein Reverse Proxy konfiguriert, der auf einen 
weiteren Webserver auf localhost umleitet. Funktioniert wie erwartet.
Auf www.domain.xyz ist eine weitere Website konfiguriert, prinzipiell 
wie die Hauptdomain (domain.xyz). Dieser VirtualHost macht mir Probleme. 
Die DNS-Records sind korrekt eingerichtet (alle verweisen auf die feste 
IP-Adresse des Servers).

(P.S. Die Domains heißen natürlich anders, ich habe sie generisch 
umbenannt, ohne weitere Auswirkungen - alphabetische Abfolge beim Laden 
der Konfigurationsdateien bleibt auch unverändert. Außerdem habe ich 
sämtliche Infos zu den HTTP-VirtualHosts auf Port 80 der 
Übersichtlichkeit halber weggelassen, weil sie in Bezug auf das 
Verhalten der HTTPS-VirtualHosts ohne Bedeutung sein dürften.)

Hier die wesentlichen Konfigurationsdateien:

root@domain:~# cat /etc/apache2/sites-enabled/aaa.domain.xyz-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName aaa.domain.xyz
        Protocols h2 h2c http/1.1
        H2Direct on
        SSLProxyEngine on
    
        ProxyPassMatch (.*)(\/websocket)$ "ws://127.0.0.1:12345/$1$2"
        ProxyPass / "http://127.0.0.1:12345/"
        ProxyPassReverse / "http://127.0.0.1:12345/"

        SSLCertificateFile /etc/letsencrypt/live/aaa.domain.xyz/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/aaa.domain.xyz/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf

        SetEnvIf Host "^(.*)$" THE_HOST=$1
        RequestHeader setifempty X-Forwarded-Proto https
        RequestHeader setifempty X-Forwarded-Host %{THE_HOST}e
        ProxyAddHeaders Off
</VirtualHost>
</IfModule>

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName domain.xyz
        DocumentRoot /var/www/html/domain.xyz/
        Protocols h2 h2c http/1.1
        H2Direct on

        <Directory /var/www/html/domain.xyz/>
                Options +FollowSymlinks
                AllowOverride All
                Require all granted
        </Directory>

        <IfModule mod_headers.c>
                Header always set Strict-Transport-Security "max-age=15552000"
        </IfModule>

        SSLCertificateFile /etc/letsencrypt/live/domain.xyz/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/domain.xyz/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

root@domain:~# cat /etc/apache2/sites-enabled/www.domain.xyz-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName www.domain.xyz
        DocumentRoot /var/www/html/www.domain.xyz/
        Protocols h2 h2c http/1.1
        H2Direct on

        <Directory /var/www/html/www.domain.xyz/>
                Require all granted
                Options +Indexes
        </Directory>

        SSLCertificateFile /etc/letsencrypt/live/www.domain.xyz/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/www.domain.xyz/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Außerdem zur Info:

root@domain:~# apachectl -S
VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server aaa.domain.xyz (/etc/apache2/sites-enabled/aaa.domain.xyz-le-ssl.conf:2)
         port 443 namevhost aaa.domain.xyz (/etc/apache2/sites-enabled/aaa.domain.xyz-le-ssl.conf:2)
         port 443 namevhost domain.xyz (/etc/apache2/sites-enabled/domain.xyz-le-ssl.conf:2)
         port 443 namevhost www.domain.xyz (/etc/apache2/sites-enabled/www.domain.xyz-le-ssl.conf:2)

Wie man sieht, ist aaa.domain.xyz der Default-Server (weil alphabetisch 
als erstes inkludiert). Nun wird beim Aufruf der URL 
https://www.domain.xyz/ nicht die richtige Seite dargestellt, sondern 
stattdessen die Konfiguration für domain.xyz verwendet. Das wundert mich 
in zweifacher Hinsicht: zum einen, weil ich in der Konfiguration für 
www.domain.xyz keinen Fehler erkennen kann und sie auch analog zur 
Konfiguration für domain.xyz ist (im Wesentlichen nur unterschiedliches 
DocumentRoot-Verzeichnis). Zum anderen, weil ich bei einer fehlerhaften 
Konfiguration erwarten würde, dass der Default-Server aaa.domain.xyz 
verwendet wird.

Wenn ich nun bei www.domain.xyz folgende zwei Zeilen zusätzlich einfüge, 
ist das Verhalten allerdings wie erwartet: für alle URLs wird eine leere 
Antwort mit HTTP-Statuscode 204 zurückgegeben.

RewriteEngine On
RewriteRule .* - [R=204]

Aufgrund dieses Verhaltens spekuliere ich, dass ein Problem mit dem 
DocumentRoot-Verzeichnis vorliegt. Die Berechtigungen fürs 
DocumentRoot-Verzeichnis sind in beiden Fällen 0755, für die enthaltenen 
Dateien (insb. index.html, index.php) 0644. Für beide VirtualHosts im 
Prinzip gleich.

Hat jemand eine Idee, wo der Fehler liegt? Gibt es eine Möglichkeit, den 
"Entscheidungsprozess" von Apache bei der Zuordnung der Anfragen zu den 
VirtualHosts zu debuggen?

Die mir bekannten üblichen Anfängerfehler dürften es nicht sein, d.h. 
die VirtualHosts sind aktiviert und die Apache-Konfiguration wurde neu 
geladen bzw. auch der Server bereits mehrmals neu gestartet (siehe auch 
Ausgabe von "apachectl -S").

Grüße und guten Rutsch
vorticon

[Dink (Gast)]

Hast Du mal mit \_default\_ probiert?

*\_default\_ vhosts for all ports*

Catching every request to any unspecified IP address and port, i.e., an 
address/port combination that is not used for any other virtual host.

<VirtualHost _default_:*>
  DocumentRoot /www/default
</VirtualHost>

https://httpd.apache.org/docs/2.2/vhosts/examples.html#default

[Dink (Gast)]

Hmm die Formatierung funktionierte in der Vorschau noch... :-)

[Vorticon X. (vorticon)]

Hi, danke, evtl. probiere ich es aus, aber ich möchte nicht zu viel 
experimentieren, um den laufenden Betrieb des Servers nicht zu 
gefährden. Würde gerne verstehen, was ich falsch mache.

[Vorticon X. (vorticon)]

Hi zusammen, noch ein Versuch, kann jemand etwas zu dem eingangs 
geschilderten Problem sagen?

[Martin (Gast)]

Was sagen denn die DNS records? Zeigen alle auf die gleiche IP?

[Vorticon X. (vorticon)]

Ja, es gibt 3 records (domain.xyz, aaa.domain.xyz, www.domain.xyz) - 
alle verweisen auf die gleiche IP

[Nur_ein_Typ (Gast)]

Vorticon X. schrieb:
>

> root@domain:~# apachectl -S
> VirtualHost configuration:
> *:443                  is a NameVirtualHost
>          default server aaa.domain.xyz 
> (/etc/apache2/sites-enabled/aaa.domain.xyz-le-ssl.conf:2)
>          port 443 namevhost aaa.domain.xyz 
> (/etc/apache2/sites-enabled/aaa.domain.xyz-le-ssl.conf:2)
>          port 443 namevhost domain.xyz 
> (/etc/apache2/sites-enabled/domain.xyz-le-ssl.conf:2)
>          port 443 namevhost www.domain.xyz 
> (/etc/apache2/sites-enabled/www.domain.xyz-le-ssl.conf:2)
>

Ich vermute nur, aber es könnte vielleicht mit der Reihenfolge 
zusammenhängen. Da kann es helfen, Deinen Konfigurationsdateien jeweils 
Präfixe wie 10_, 20_, 30_ in die Dateinamen zu schreiben... Versuch 
macht kluch. Bei einer ähnlichen Konfiguration war das bei mir die 
Lösung.

[Vorticon X. (vorticon)]

Hallo zusammen,

Wahrscheinlich entsteht das Problem dadurch, dass zu einer IP-Adresse 
mehr als ein namensbasierter, SSL-verschlüsselter VirtualHost nur dann 
unterstützt wird, wenn für alle VirtualHosts das gleiche SSL-Zertifikat 
(etwa Wildcard-Zertifikat) gültig ist. Ich hatte unterschiedliche 
Zertifikate für die einzelnen Subdomains (siehe Konfiguration oben).

Ich habe gerade nicht die Möglichkeit, am laufenden System das Problem 
exakt einzugrenzen. Aber ich vermute stark, dass der beschriebene 
Sachverhalt ursächlich ist. Falls jemand mit einem ähnlichen Problem auf 
diesen Thread stößt, könnte das der Lösungsansatz sein.

Grüße
vorticon

Eine Erläuterung des Problems findet sich hier:

https://cwiki.apache.org/confluence/display/HTTPD/NameBasedSSLVHosts

As a rule, it is impossible to host more than one SSL virtual host on the same IP address and port. This is because Apache needs to know the name of the host in order to choose the correct certificate to setup the encryption layer. But the name of the host being requested is contained only in the HTTP request headers, which are part of the encrypted content. It is therefore not available until after the encryption is already negotiated. This means that the correct certificate cannot be selected, and clients will receive certificate mismatch warnings and be vulnerable to man-in-the-middle attacks.

In reality, Apache will allow you to configure name-based SSL virtual hosts, but it will always use the configuration from the first-listed virtual host (on the selected IP address and port) to setup the encryption layer.

[Gästin (Gast)]

Vorticon X. schrieb:
> Hallo zusammen,
>
> Wahrscheinlich entsteht das Problem dadurch, dass zu einer IP-Adresse
> mehr als ein namensbasierter, SSL-verschlüsselter VirtualHost nur dann
> unterstützt wird, wenn für alle VirtualHosts das gleiche SSL-Zertifikat
> (etwa Wildcard-Zertifikat) gültig ist. Ich hatte unterschiedliche
> Zertifikate für die einzelnen Subdomains (siehe Konfiguration oben).

Nö, das ist dank SNI heute kein Problem mehr:

https://de.wikipedia.org/wiki/Server_Name_Indication

[Gästin (Gast)]

Wenn das stimmt…

> Wenn ich nun bei www.domain.xyz folgende zwei Zeilen zusätzlich einfüge,
> ist das Verhalten allerdings wie erwartet: für alle URLs wird eine leere
> Antwort mit HTTP-Statuscode 204 zurückgegeben.
>
> 1 RewriteEngine O
> 2 RewriteRule .* - [R=204]

…ist die naheliegenste Vermutung, dass die unbekannte Software auf dem 
VHost (falls es nicht nur statische HTML Seiten sind) auf die falsche 
Domäne konfiguriert ist und mit einem Redirect Antwortet.

[oszi40 (Gast)]

Selbst eingebaute Fehler sind immer die schönsten. Eigentlich sollte 
doch eine Gegenprobe nur mit http die grundsätzliche Funktion prüfen 
können? Prüfpunkte? Dann später schrittweise Zertifikate... prüfen usw.?