Stellen Sie http (Port 80) und https (Port 443) auf demselben VirtualHost bereit

Ich muss meinen VirtualHost unter Apache so einrichten, dass er sowohl unter http als auch unter https (unter Verwendung von Standardports) ausgeführt wird.

Wenn ich die SSL-Engine aktiviere (siehe unten), wird an Port 80 eine Fehlermeldung angezeigt.

Der Grund dafür ist, dass Teile der Website SSL sein müssen, andere Teile jedoch nicht. Wie kann ich beide http + https auf der Site bedienen?

Hier ist meine virtuelle Hostdatei ....

NameVirtualHost *

<VirtualHost *>
        ServerAdmin webmaster@localhost
        ServerName mysite.co.uk
        DocumentRoot /var/www/mysite/public
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/mysite/public>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /var/log/apache2/access.log combined
        ServerSignature On

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

     #SSL STUFF...
      SSLEngine on
      SSLCertificateFile /etc/apache2/crts/mysite.crt
      SSLCertificateKeyFile /etc/apache2/crts/mysite.key
      SSLCertificateChainFile /etc/apache2/crts/DigiCertCA.crt


</VirtualHost>

— kron
quelle

Antworten:

Sie können dies nicht auf einem virtuellen Host tun, da Apache wissen muss, welcher über SSL spricht und welcher nicht (Anmerkung: nginx hat dieses Problem nicht, Sie können ihm mitteilen, welche Listen-Direktiven sich auf SSL beziehen. einer der vielen Gründe, warum ich es liebe).

Die Art und Weise, wie ich dies in Apache verwalte, besteht darin, alle meine nicht SSL-bezogenen Konfigurationen in eine separate Datei zu packen und dann die beiden vhosts nebeneinander zu konfigurieren, wobei jeder die standortspezifische Konfigurationsdatei in der Zeilengruppe vhost wie folgt enthält :

<VirtualHost 192.0.2.12:80>
    Include /etc/apache2/sites/example.com
</VirtualHost>

<VirtualHost 192.0.2.12:443>
    SSLEngine On
    # etc
    Include /etc/apache2/sites/example.com
</VirtualHost>

— womble
quelle

Es scheint ein Problem in Apache vHost zu sein, aber es erledigt den Job, ohne dass die Konfiguration wiederholt werden muss.

SSLCertificateFile /srv/.ssl/self/server.crt
SSLCertificateKeyFile /srv/.ssl/self/server.pem

# REQUIRED
<VirtualHost *:80>
    DocumentRoot /srv/www/badhost
</VirtualHost>

<VirtualHost *:80 *:443>
    SSLEngine On
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /srv/www/example.www
</VirtualHost>

— VarunAgw
quelle

Das ist wirklich komisch, existiert aber!

— user77376

Das hat so gut geklappt, wie man es von einem solchen Kludge erwarten kann - fast, aber nicht ganz! Ich habe festgestellt, dass Apache 2.4.10 die Umgebungsvariable SERVER_PORT auf 443 setzt, anstatt den Port zu verwenden, an dem die Anforderung eingegangen ist (abhängig von 80 oder 443). <IMAGINARY_PARAGRAPH_BREAK> Schade, denn ich hatte gehofft, dies nutzen zu können, da ich wirklich eine Datei pro virtuellem Host behalten wollte. <IMAGINARY_PARAGRAPH_BREAK> Außerdem benötigen Sie eine ServerName-Direktive im oberen <VirtualHost>, andernfalls werden versehentlich Anfragen verschlungen. Setze es auf ServerName badhost.bad oder so.

— Daniel Beardsmore

@DanielBeardsmore: Ich habe dies gerade mit 2.4.18 aus RH Software-Sammlungen getestet, und das scheint auf die Standardeinstellung von zurückzuführen zu sein UseCanonicalPhysicalPort Off. Wenn Sie diese Option aktivieren, wird anscheinend der tatsächliche Port verwendet. (Lustigerweise musste ich das SSLEngine Onin meinem doppelt genutzten vhost weglassen und bekam standardmäßig Port 80.)

— Ulrich Schwarz

@DanielBeardsmore: FWIW, %{HTTPS}wird auch korrekt eingestellt, ist aber %{REQUEST_SCHEME}nicht (immer http). Ich fühle mich jedoch dumm, eine Feature-Anfrage für eine UseCanonicalRequestSchemeDirektive einzureichen.

— Ulrich Schwarz