☰

Warum stellt die Nicht-SSL-Version meines SSL-fähigen Apache-Hosts Inhalte von einem anderen Host bereit?

tag-icon • tag-icon apache-http-server ssl virtual-host
Warum stellt die Nicht-SSL-Version meines SSL-fähigen Apache-Hosts Inhalte von einem anderen Host bereit?

Ich habe einige Websites, die auf dem lokalen Host mit Apache/Ubuntu laufen.

Ich habe gerade erfolgreich selbstsignierte Zertifikate für eine davon installiert, nennen Sie es securesite.local. Eine andere Nicht-SSL-Site, nennen Sie es, insecuresite.localfunktioniert auch wie erwartet.

Das heißt, wenn ich navigiere zu

https://securesite.local
http://insecuresite.local

Jeder von ihnen liefert den richtigen Inhalt.

Wenn ich jedoch dorthin navigiere, http://securesite.localwerden Inhalte voninsecure.local

Meine /etc/hosts enthält

127.0.1.1 securesite.local
127.0.1.1 insecuresite.local

/etc/apache2/apache2.conf enthält

IncludeOptional sites-enabled/*.conf

Es enthält keine expliziten Verweise auf Securesite oder Insecuresite.

ls /etc/apache2/sites-enabled

securesite.conf insecuresite.conf

insecuresite.conf enthält (hier abgekürzt)

<VirtualHost insecuresite.local:80>
    ServerName insecuresite.local
    ServerAlias insecuresite.local
    # ...

securesite.conf enthält (hier abgekürzt)

<VirtualHost securesite.local:443>
    ServerName securesite.local
    ServerAlias securesite.local
    # ...

Ich möchte, dass Apache Verbindungen zu securesite.local über jeden anderen Port als 443 ablehnt und nicht auf die Bereitstellung von Inhalten von anderen Sites zurückgreift, die Datenverkehr auf diesem localhost:80 zulassen.

Warum passiert das und wie kann ich es stoppen?

Antwort1

Basierend auf Ihrer insecuresite.conf und securesite.conf Datei lauscht einer auf Port 80 und der andere auf 443. Wenn Sie zuhttp://securesite.local, Ihr Browser fordert Daten von Port 80 an und das einzige, was über Port 80 bereitgestellt wird, ist insecuresite.local.

Um dies zu beheben, müssen Sie einen virtuellen Host für securesite.local:80 definieren und ihn auf https umleiten lassen. Außerdem müssen Sie sicherstellen, dass Sie Folgendes NameVirtualHost *in Ihrer apache2.conf-Datei haben.

Ihre beiden Conf-Dateien würden dann ungefähr wie folgt aussehen:

<VirtualHost *:80>
    ServerName insecuresite.local
    ServerAlias insecuresite.local
    # ...

Und

<VirtualHost *:80>
    ServerName securesite.local
    ServerAlias securesite.local
    Redirect permanent / https://securesite.local
    # ... 
<VirtualHost *:443>
    ServerName securesite.local
    ServerAlias securesite.local
    # ...

Wenn die Option „NameVirtualHost“ aktiviert ist, untersucht Apache die Servernamen und Serveraliase und stellt die Daten entsprechend bereit.

Antwort2

Sockets werden gebunden an und Verbindungen hergestellt anIP-Adressen, keine Hostnamen.Da beide virtuellen Hosts identische IP-Adressen haben, gibt es nur einen Listener-Socket für beide, und Apache kann erst wissen, welche Domain angefordert wird, wennnaches hat die Verbindung akzeptiert – es muss die HTTP-Anforderung (oder den TLS-SNI-Handshake) empfangen.

Dateien sites-enabledwerden in asciibetischer Reihenfolge gelesen, daher können Sie einen „Fallback“-Vhost in einer Datei mit dem Namen oder so ähnlich einrichten sites-enabled/00-default.conf. (Mit anderen Worten: Lassen Sie ihn vor allen anderen Vhosts für dieselbe IP auflisten.)

verwandte Informationen