Servir http (port 80) et https (port 443) sur le même VirtualHost

J'ai besoin de configurer mon VirtualHost sur Apache pour servir à la fois sur http et https (en utilisant des ports standard)

Si j'active le moteur SSL (comme ci-dessous) - j'obtiens une erreur sur le port 80.

La raison en est que certaines parties du site doivent être SSL, mais pas d'autres. Comment puis-je faire pour servir les deux http + https sur le site?

Voici mon fichier d'hôte virtuel ....

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>

— couronne
source

Réponses:

Vous ne pouvez pas faire cela dans un hôte virtuel, car Apache a besoin de savoir lequel va parler SSL et lequel n'est pas (sidenote: nginx n'a pas ce problème, vous pouvez lui dire quelles directives d'écoute se rapportent à SSL; une des nombreuses raisons pour lesquelles je l'aime).

La façon dont je gère cela dans Apache consiste à placer toutes mes configurations non liées à SSL dans un fichier séparé, puis à configurer les deux vhosts côte à côte, chacun incluant le fichier de configuration spécifique au site dans la strophe vhost, comme ceci :

<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
source

Cela semble être un problème dans Apache vHost, mais il fait le travail sans avoir à répéter la configuration.

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
source

C'est vraiment bizarre, mais ça existe!

— user77376

Cela a fonctionné aussi bien que vous pourriez vous attendre d'un tel kludge - presque, mais pas tout à fait! J'ai trouvé qu'Apache 2.4.10 définit la variable d'environnement SERVER_PORT sur 443 au lieu d'utiliser le port sur lequel la demande est entrée (80 ou 443 selon). <IMAGINARY_PARAGRAPH_BREAK> Dommage, car j'espérais pouvoir l'utiliser, car je voulais vraiment garder un fichier par hôte virtuel. <IMAGINARY_PARAGRAPH_BREAK> De plus, vous aurez besoin d'une directive ServerName à l'intérieur du <VirtualHost> supérieur, sinon elle engloutira les demandes par erreur. Définissez-le sur ServerName badhost.bad ou quelque chose.

— Daniel Beardsmore

@DanielBeardsmore: Je viens de le tester avec 2.4.18 des collections RH Software, et cela semble être dû à la valeur par défaut de UseCanonicalPhysicalPort Off. Si vous activez cette option, vous semblez utiliser le port réel. (Curieusement, j'ai dû laisser le SSLEngine Ondans mon vhost doublement utilisé et j'ai obtenu le port 80 par défaut.)

— Ulrich Schwarz

@DanielBeardsmore: FWIW, %{HTTPS}sera également défini correctement, mais %{REQUEST_SCHEME}ne l'est pas (toujours http). Je serais stupide de mettre une demande de fonctionnalité pour une UseCanonicalRequestSchemedirective, cependant.

— Ulrich Schwarz